It would be nice if someone worked on actually improving the terminal experience. Selecting, copying and pasting text is still pretty awful (why is the cursor an entire block rather than a I bar?). Editing multiline inputs is awful. Navigating history is so-so (even with McFly etc.). Anything more complicated than left/right/up/down fails half the time and dumps control characters instead.
Why are terminals always stuck in the 70s? Can I get a modern terminal?
FYI for editing multiline inputs there is a readline key command edit-and-execute-command that opens your $EDITOR with the currently typed command. I mapped it to C-x C-e, not sure what is the default key, if any.
For history I recommend fzf, it's easy to integrate and has one of the most efficient interfaces I've seen. Replaced my ctrl-r with it.
For copying I personally use a tmux binding that dumps the current screen into vim, letting me navigate quickly with easymotion and a mapping that automatically synchronizes the @t register with tmux clipboard.
There are better experiences (e.g. my shell has vi mode which is much nicer for editing multi-line inputs, I'm sure if I could be bothered to learn emacs/readline shortcuts that'd be another set) but they're not easily discoverable and a bit unevenly distributed.
> It would be nice if someone worked on actually improving the terminal experience.
Contour. Oh, sorry, I mean: To be honest? There are plenty of young terminals that work on that, it's not just Contour, but also WezTerm, foot, Ghostty, Warp, and Terminal.click (even though I am strongly against their architecture). Also Charm and Fig should earn an honorable mention.
> Selecting, copying and pasting text is still pretty awful
Use the vi-like normal mode in Contour and that should(tm) fix almost all of the above problems. At least I have almost never touched a mouse again on Contour since I've implemented modal input in Contour. Well, I use the mouse, casually for scrolling and procrastinating by randomly clicking around. :)
> (why is the cursor an entire block rather than a I bar?).
this is configurable in recent terminals
> Editing multiline inputs is awful.
this should be implemented by your shell or readline, in case you want to improve here. your TE has nothing to do with this except that it provides the tools to realize that on the screen :)
> Navigating history is so-so (even with McFly etc.).
This is the job of the shell/readline.
> Anything more complicated than left/right/up/down fails half the time and dumps control characters instead.
I really cannot related that claim to anything I am experiencing in my own life. Sadly.
> Why are terminals always stuck in the 70s? Can I get a modern terminal?
To be fair, they are not named "emulator" for fun and giggles. But I agree, not every VT sequence or semantic should be blindingly implemented. Especially the Unicode case on Terminals were always a fight against the historian terminal emulator developers. I asked myself why a lot on that matter. My theory? Because it potentially requires those existing terminals to fully re-write their core code base in order to be fully (as full as it gets) Unicode aware.
This is implemented by 4 terminals (Ghostty, WezTerm, foot, Contour). One bite at a time I guess. Let's just stay positive, we can't break the world! (Terminal.Click? You listening?) But we should certainly break here and there when it makes sense and also not blindingly implement the 70s again. The GUI has also good moments and can live next to the TUI ;)
Outside of "line at a time" i/o (a rarely used mode where an entire line is edited locally and then sent to the host), most of what users see is as interactive is controlled by the program you are interacting with. The terminal just takes commands from the host and does what it is told. BTW, line at a time mode isn't used that much. The only thing I use that uses line at a time mode is telenet in LINEMODE.
> Navigating history is so-so
Yes, that is because the program you are likely interacting with where history is relevant implements it's own repl or command line (i.e. bash, zsh, python, etc...) and it is responsible for it's own history and may implement it completely differently than say, bash or zsh.
> Why are terminals always stuck in the 70s? Can I get a modern terminal?
We do have a modern terminal: the web browser... and it's pretty nice.
There have been a ton of tries at more modern terminals, but ultimately, they end up really being limited by the software running in the terminal session. In the 90s we had a ton of commercial terminal emulators that would allow you to create full guis, complete with dialogs and forms. In the 00's there were a few tries at terminals that would allow html output and embedding of html forms for input (can't remember the names of them). I suppose there's also the whole X11 thing... which is so good enough that it's really hard to kill.
Let's get back to character mode:
A lot of interactive terminal software is built using different libraries - so sometimes you get a terminal gui based on ncurses, terminal.gui, or something else... here's a list: https://github.com/rothgar/awesome-tuis#libraries. Most of these libraries try to use most of the features in your terminal emulator, but often, just use stuff that is in everything.
For command line programs (i.e. just type a command), a lot of the experience is dictated by the parser used by the tool and whatever the underlying operating system has for passing arguments. Some shells and terminal emulators (like iTerm2 on mac) try to smooth this out, but again, there's a lot of variety in command line parsers.
Probably the biggest modern improvement in the shell world was gettext and various command-line completion libraries which allows command parameter completion if the developer supports it or uses a parser that supports completion. But none of this is the terminal itself doing the work.
You're doing the classic thing of explaining why things are bad and thinking that that is the end of the story.
> The terminal just takes commands from the host and does what it is told.
> that is because the program you are likely interacting with where history is relevant implements it's own repl or command line (i.e. bash, zsh, python, etc...) and it is responsible for it's own histor
I know!!!
My point was why is nobody working on fixing these issues?
The answer is not because it can't be done. That just shows lack of imagination.
> You're doing the classic thing of explaining why things are bad and thinking that that is the end of the story.
If it was the end of the story, progress would stop. Saying we need a better terminal and then talking about things that run using a terminal ui, but are not the terminal really is the issue here.
> My point was why is nobody working on fixing these issues?
People are working on the problem. There are tons of shells, TUIs, command parsers, web interfaces for commands and interactive apps, some software even work in TUI and GUI mode.
Perhaps a better terminal would help, but I suspect that the problem is there's not really a medium between "better terminal" and "web browser" that won't just evolve into a web browser or something like X over time.
> The answer is not because it can't be done.
No one said it can't be done. You can argue it has been done many times... X11, the web, etc.. But I think the OP was confused about what a terminal is and what the software that runs in the terminal does.
Why are terminals always stuck in the 70s? Can I get a modern terminal?