
Ask HN: What do you love/hate about terminals? Would you change them? - terminal-survey
I&#x27;m part of a small group that is working on a new set of protocols for terminals and shells, in order to move terminal handling out of the kernel as much as possible, and to replace the huge organically grown mess of ANSI escape sequences, terminfo databases, and so on.<p>I&#x27;m posting this from 34C3, where I&#x27;m asking people the same questions:<p>- What do you <i>love</i> about terminals?<p>- What do you <i>hate</i> about terminals?<p>- If you had to build one from scratch, how would you do it?<p>If you do not wish to answer in public, you can also write a mail to 34c3-terminal-survey at posteo dot de.<p>[I&#x27;m posting from a throwaway account because my Github links to the work that we have started on this, and I don&#x27;t want to bias the survey by having you look at it before answering.]
======
waqf
Fix scrollback. Sometimes I run a command and it has 50,000 lines of output.
Either I don't care about the output — in which case I should be able to click
to fold it up and be able to see my history before that one command — or I do
care about it, in which case I want every scroll, search and export operation
that a full-fledged document editor would have.

In either case, UI latency shouldn't suffer, scroll bars shouldn't become
unusable, my scrollback history before that one command shouldn't be thrown
away — Mathematica notebook style, as another commentator suggests, might work
well here.

~~~
EpicEng
I'm not sure I understand; if you don't care about the output then send it to
/dev/null. If you do care then pipe it to an editor. A terminal is not a text
editor (I mean, I suppose it could be, but that seems like a rather large
scope change.)

~~~
terminal-survey
I think the problem is that you only know if you care about the output after
the fact. For example, if "make" runs through, I usually don't care about the
output. But if "make" fails, then I want to read the error messages.

As I said somewhere else, we have a concrete solution in mind for implementing
folding as GP describes.

~~~
EpicEng
I don't know that make is a good example here. This is a tool you use
constantly, so I imagine you'd know to pipe std err if you wanted its output.
We seem to be talking about turning the terminal into a full blown editor
(when we already have editors...) to satisfy a rather limited use case of
'oops, guess I have to run that again."

But hey; your time to spend :)

~~~
khedoros1
> We seem to be talking about turning the terminal into a full blown editor
> (when we already have editors...) to satisfy a rather limited use case of
> 'oops, guess I have to run that again."

That seems like an incredibly _common_ use case to me. It's common for a
command to have a lot more output than I originally expected, and when it
happens, I usually want to examine that output in detail. It would be great to
retroactively be able to open captured output in a text editor, dump it to a
file, pipe it to another tool, or collapse it.

I don't really want to _edit_ the output in the terminal, but it would be
great to be able to say "oops, do X with stdout from that last command, and do
Y with stderr".

~~~
afarrell
FWIW, I also find myself wanting this.

------
skrebbel
I think that the autocomplete story is abysmal. Modern IDEs can tell me
exactly what can follow after a certain piece of text, and even the best tab
completion in terminals is limited, ugly, and text-mode for no good reason.

Some protocol for a _real_ dropdown rendered in the style of the OS, plus a
standard data format that allows tool builders to specify options, their
meanings and the kinds of allowed parameters in a structural way (much like
doccomments in code), is direly needed.

If I type "git " I want to see "add" as an option, with docs in a tooltip as I
navigate the options. When I "git add " I want to see a list of files that
make sense to add, eg only files that can be staged right now.

I want this to be consistent across commands, I want any shell to be able to
add support for this and I want any command line program to be able to add
support for this.

~~~
terminalcommand
> If I type "git " I want to see "add" as an option, with docs in a tooltip as
> I navigate the options. When I "git add " I want to see a list of files that
> make sense to add, eg only files that can be staged right now

With fish you can customize auto completion for individual commands with full
color and tooltip support.

As a long time emacs user I want to believe that much of the required
functionality for menus can be achieved via a text only format (either using
standard escape codes or a markup language).

I completely agree that we need to be able to incorporate native UI elements
in CLI programs.

Recently I stumbled upon Steve Jobs's presentation of Next computers and the
initial UIkit. Jobs himself programmed without writing a single line of code,
only using the built in interface builder. This was in the 80s, now the year
is 2017 and we are still trying to remember the parameters for tar to extract
files :)

I think the future should not rely on terminals where we extensively type and
read. There should be drop-down menus for all applications, whether text based
or GUI based. And these menus should be able to incorporate system-native
dialogs e.g choose a file, choose a font etc.

And I'd want PostScript support to all terminals. Green on black mono fonts
are cool but we have 4K displays now, come on! I want to be able to specify
font, show images, draw charts etc. in a terminal window.

Frankly the future of terminals should look like Python Notebooks such as
Jupyter. We need to be able to use cool fonts graphics UI elements and we need
to be able to share our terminal "page" with others.

~~~
murukesh_s
> Recently I stumbled upon Steve Jobs's presentation of Next computers and the
> initial UIkit. Jobs himself programmed without writing a single line of
> code, only using the built in interface builder. This was in the 80s, now
> the year is 2017 and we are still trying to remember the parameters for tar
> to extract files :)

I watch it regularly. Every time I see even seasoned developers takes weeks or
even months for building even a simple application, whether it's frontend or
backend, I wonder if we developers have a subconscious bias towards tougher
way of building things instead of a much easier way. Visual basic comes into
my mind. Visual basic is probably inspired by interface builder and had
similar rapid development features. Where/when have we lost it?

> Frankly the future of terminals should look like Python Notebooks such as
> Jupyter.

I second that. A terminal should ultimately do it's purpose. Not mimic a
1950's thin client terminal with 80x25 resolution and dark colors (Nothing
against dark theme, just saying). A user whether a normal user or power user
or even a developer shouldn't be bothered with remembering the exact parameter
or it's structure. It should be completely scriptable, but it need not appear
like existing terminals.

~~~
sametmax
> I wonder if we developers have a subconscious bias towards tougher way of
> building things instead of a much easier way.

That and the fact you we don't know everything that's possible and stick to
what we know.

But, there is another side of the story: reusability is hard, plus similarity
and equality are very different things. Generalizing a problem can be more or
less productive depending of your situation. Also learning how to use
something and bend it to your needs can be an mistake too on the long run.

Mix complexity, money, human factors in that and you get the average IT
project.

Which is still awesome if you ask me. Current softwares have many warts, but
they are so freaking amazing.

------
ordu
I love terminal because it is universal tool. I use urxvt in X-session, or
emacs-shell sometimes. I can use it over ssh. I have kernel console for times
when Xorg is broken. It is great. Great for user and for programmer too. As
programmer I need not to fo any special tricks for my program was able to work
with any terminal. It just works. All I need is printf, or something like. It
is much simplier than any GUI toolkit use. Moreover, I can write programs for
microcontrollers and communicate with them through serial line. Terminal is
universal tool.

But this fun ends quickly if I need more than just output text sequentially. I
would have nothing wrong with an idea of esc-sequences, if those sequences
were standartized. But esc-sequences is not the full story -- line
disciplines, complex states of terminal, heaps of historical garbage. There is
ncurses, it can hide a lot of complexity but not all. And I do not like
ncurses, maybe due to unhided complexity.

If I had to build terminal from scratch... At first I would state one curious
fact: if decades ago terminal was extremly dumb device connected to a
relatively powerful computer, now the reverse is the case: terminal runs on a
relatively powerful hardware while a program working with a terminal can be
run on a microcontroller with 2Kb RAM. So I see no reason to allow a terminal
to be a dumb-terminal. A terminal could be pretty smart now. At least it can
describe his capabilities in a universal format, for client doesn't have to
consult with terminfo database, trying to guess what this terminal can do and
what it cannot do.

And the second is to define clear APIs. Every time I try to do something with
a terminal I need to spend a couple of days reading texts just to remind
myself what the hell a terminal is.

~~~
terminal-survey
> At first I would state one curious fact: [...]

That part is so nicely said I might just steal it for our manifesto. :)

------
ansible
Here are my comments and concerns.

1\. Minimal latency from keyboard to screen.

2\. As others have mentioned here, awareness of line wrap, so that cut and
paste work correctly at all times. Not just for raw output from a command.
Editors too should communicate with the terminal to indicate that it is
wrapping lines.

3\. 24-bit color.

4\. Apps (shells, editors) can query and set the window icon as well as the
window title.

5\. Integrated graphics display. So that I can just 'cat' a picture to display
it in the terminal window, instead of using an external application.

~~~
jstimpfle
"cat" could never work of course, or the general idea of a terminal that has
only a pair of input/output streams must be given up. I don't think people are
willing to do that.

A sensible protocol to draw raster graphics would be nice, though. (And it
might exist, I don't even know). I don't care whether I need to type "cat" or
the name of a terminal-based image viewer.

~~~
terminal-survey
> "cat" could never work of course

We have an idea in that direction, where each program in a pipeline can
optionally specify a file type, and the last file type hint in the pipeline
determines how the stdout is rendered. So if you have "cat image.jpg", then
"cat" can indicate a file type of image/jpg, causing stdout to be interpreted
as an image. But if you have "cat image.jpg | grep foo" (just making something
up here), then grep can indicate a file type of application/octet-stream
because it cannot guarantee what the file type is.

The tricky part, from what I can see, is explaining the pipeline topology to
the terminal, so that it knows that "grep" comes after "cat", even though
command parsing happens in the shell only. That's still a big unknown. A
previous project in this area (TermKit) mandated that applications specify a
"Content-Type" header (like in HTTP) in their stdout, but that would break
most existing programs, so it's not an option for us.

~~~
jstimpfle
I would not recommend that. That would be the source for endless bikeshedding
and could never satisfy all people. (See the mess that HTTP / REST are).

It's not a problem to have this handled in the shell such that the output is
rendered in such a way as to please the terminal. You can do this manually
(e.g. append a "| display-jpeg-in-terminal" command to the pipeline), or use a
magic bytes based file viewer.

Look at "run-mailcap" or its shortcuts like "see". It does basically that, and
can also be fed through standard input (which covers the piping situation).

~~~
baq
if shells had some more types than a stream of bytes, it'd make sense for
'image' type data to be displayed as images. the pipes you mention are then
simply type casts or conversion functions.

~~~
jstimpfle
I don't know what you think is missing. "Displaying 'image' type data as
images" totally works. Are you aware of magic bytes (which I mentioned above)?

~~~
baq
never used them, but i'm thinking more in terms of powershell (pretty sure
displaing images isn't something it does though). if images in particular work
ok then that's one thing that i can scratch off my list of annoyances with
ssh.

~~~
jstimpfle
If you want a few tips how to type less, feel free to write me an email
describing your problem.

------
beefhash
> \- What do you love about terminals?

The cursor is (generally) an absolute source of truth: Terminals usually
behave very predictably. A good terminal does not get in my way or have any
bells and whistles. Text goes in, output goes out, there's support for
whatever the application needs wrt graphical capabilities and cursor
manipulation. That's it. I don't want to have to deal with "oh god I
accidentally clicked on a link, let's wait for the firefox tab I didn't need
to open".

They're text-based and thus it's very difficult to introduce distraction or
overly busy interfaces. Scripting being part of the terminal culture is great.
Automation is often at least somewhat thought about.

> \- What do you hate about terminals?

There used to be an issue with terminals not being encoding-aware and having
big issues with UTF-8. Fortunately, it seems these days are long gone. One
thing I loathe is when terminals try to look or behave fancy. Get out of my
way, please. If you have that much dev time to spare, please make sure that
bitmap fonts actually work.

Not about terminals themselves, but about the ecosystem around it: people
assume bash is present and always in /bin/bash. That's an unreasonable
assumption. Tab completion is a crapshoot since it's not context aware and
_extending_ tab completion for the major shells (bash, zsh, fish) is still an
unsolved task.

> \- If you had to build one from scratch, how would you do it?

Assuming I can look at prior work, I'd first look at prior work. Ideally
_simple_ prior work, like st. I'd also read as much documentation on the VT100
and ANSI escape sequences as I possibly could, since I think that's (still?)
kind of the gold standard.

Anything related to mouse support, "integration" with a desktop, trying to
outsmart the shell at tab completion are anti-features.

~~~
hollerith
>Anything related to mouse support, . . . are anti-features

How does mouse support harm you?

The change I'd most like to see to Apple's Terminal.app is that when I want
make an edit to the middle of a command line that has not been sent to the
shell yet, I can use the pointing device to move the cursor to the location of
the intended edit. How would that change harm you?

Why isn't it enough that you are able to work the way you want to work?

Why are you in addition advocating preventing a different way of working that
is preferred by many people?

(Most of the time, I use an emacs mode written by myself to issue command
lines to a shell, and that mode allow me to use the pointing device to move
the cursor, but when I've introduced a bug into the emacs-lisp code that I
maintain, I have to use Terminal.app to recover from the bug. I also have to
use Terminal.app when setting up a new Mac.)

~~~
otron
>The change I'd most like to see to Apple's Terminal.app is that when I want
make an edit to the middle of a command line that has not been sent to the
shell yet, I can use the pointing device to move the cursor to the location of
the intended edit.

I recall being able to do this by holding down the alt key as I left clicked
where I wanted the cursor to be relocated.

There's nothing wrong with mouse support in itself. Being able to move the
cursor, select text, and in general interface with the OS or an application
using a mouse is great. However being _forced_ to use the mouse for any kind
of general OS or application interfacing feels like an injustice. A macOS
specific example would be moving a window between desktops. The last time I
used macOS there was no native way to do this without using the mouse. I had
to drag the window to the desired desktop (either by dragging it towards the
edge of the current desktop or by going to the desktop overview mode and
dragging it onto the desired desktop).

~~~
hollerith
>I recall being able to do this by holding down the [option] key as I left
clicked

Thanks!

------
gaius
Well it is obvious to me that terminal handling and indeed the shell itself
should be absorbed into systemd....

On a more serious note, the terminal has to "just work", its role is to host
shells, ncurses apps, and so on. It doesn't need to have any clever features,
it just needs to be a blank canvas, one that is tolerant of its guests doing
weird stuff and able to recover gracefully. All the "cleverness" should be in
the shell, so it can be swapped out for another one easily.

~~~
jdc0589
> Well it is obvious to me that terminal handling and indeed the shell itself
> should be absorbed into systemd....

systemd is like that emacs of process supervisors.

~~~
pecg
Except that emacs is less bloated and doesn't crash as often, and not being
and important program for the system, one can easily replace it with more
simple software.

~~~
sigjuice
This is simply not true about Emacs. I have to restart my Emacs every couple
of months because it gets too slow. I am not quite sure how to debug this.

------
jdc0589
First, if I want to come up with a setup that includes a modern terminal
emulator with lots of features, a decent number of extensions and plugins for
things like zsh, etc..., I will INEVITABLY end up with a something that:

1) has way more input latency that it should have (iterm2, Ive had to just
fall back to Terminal.app)

2) takes WAY too long to launch a new bash/zsh/whatever session if I split a
window (cause parsing thousands of lines of autocomplete code written in bash,
profiles, etc... is SLOW). Shit, just installing nvm and sourcing all its crap
adds an easy 400ms to session start time.

3) works on one, maybe two platforms at best.

Second: I understand that using a terminal for everything is inevitably going
to be less efficient that a UI in very specific scenarios, but this ends up
being true way too often, and a large part of it is due to the CONSTANT need
to parse/marshal/unmarshal output format of one program to get it right for
input somewhere else. Some of that is the terminal's fault (along with the
whole CLI ecosystem), but a lot of it is just cause there are 9000 different
competing formats for human readable structured data. Powershell really tried
to get this right, and I salute them for it.

Third: terminals have been around for a long time, and they've come up with
their own conventions for keyboard shortcuts/etc... over the decades; I get
it. But its time to just dump that baggage and default to whatever the
standards for a particular OS are.

~~~
mr_overalls
At the risk of starting a quasi-religious argument, the object-orientation of
Powershell is one of the things I really like about it.

~~~
tonyedgecombe
It is nice although quite difficult if you are just an occasional user.

~~~
jdc0589
I've forgotten how to write powershell more times than I can remember.

------
pm215
Here's a recent pet annoyance of mine: if you have a lot of output from a
command, so you pipe it through less, and then use X cut-and-paste to copy a
multiline chunk of it to another terminal, it seems to be arbitrary whether it
pastes as a single line, or multiple separate lines split by newlines. (For
instance, resizing the xterm can change which you get.) I think this is
because cut-n-paste is handled by the terminal, but the pager is just drawing
characters at cursor positions so the terminal can only make a best guess
about multiline selections.

~~~
stevewillows
Along with this, it'd be so nice to have line numbers for certain outputs
along with a simple way of outputting a specific line to the clipboard or a
file.

~~~
signa11
iirc, there is a program called 'nl' that should do the trick

~~~
jwilk
I find "nl" pretty useless, because it only numbers non-empty lines, which is
never what I want.

There's "cat -n" which numbers all lines. (-n is not POSIX, but it's available
on at least on BSDs and Linux.)

~~~
signa11
> ... because it only numbers non-empty lines...

oh, that's just a man page lookup away. use 'nl -ba' which numbers all the
lines. default style is '-bt' which numbers only non-empty ones, as you have
experienced...

~~~
jwilk
Even with -ba (which I could never remember), nl does too much magic:

    
    
      $ printf 'foo\n\:\nbar\n' | cat -n
           1	foo
           2	\:
           3	bar
      
      $ printf 'foo\n\:\nbar\n' | nl -ba
           1	foo
      
             bar

------
erikj
My ideal modern terminal would be pretty much a reimplementation of Symbolics'
Listener:
[https://youtu.be/o4-YnLpLgtk?t=1m46s](https://youtu.be/o4-YnLpLgtk?t=1m46s)

\- A presentation-based UI, where every on-screen element is always linked to
the data it represents:
[https://dspace.mit.edu/handle/1721.1/6946](https://dspace.mit.edu/handle/1721.1/6946)

\- A powerful autocomplete that knows about possible keywords and arguments,
and can list them in a graphical fashion (e.g. a drop-down menu).

\- An ability to use any previously displayed data as input to a new command
just by clicking on it, with the UI highlighting only the things than can be
used as valid input to the current command.

\- Embedding of images and arbitrary UI widgets.

\- Sensible names for commands and their arguments, i.e. "Delete File" instead
of "rm", and ":Output Destination File /home/erikj/log" instead of ">
/home/erikj/log". This makes a lot more sense with the enhanced autocompletion
facility than the current 70s style cryptic Unix two-letter commands that were
employed because of the hardware limitations. It would be easier to learn and
less prone to errors.

~~~
jstimpfle
You are not going to get more than 10% of shell users to type ":Output
Destination File /home/erikj/log" instead of just "> home/erikj/log". Learn it
once, save typing a lot of characters, many times a day.

The idea that you should type so much more just to be "not cryptic" is as old
as COBOL. Which, as most people would agree, was not a good idea.

~~~
erikj
Why do you think I mentioned the autocompletion facility? Shell users won't
have to type any more characters than they do now. Please give Genera a try in
the emulator to see how it would work with your own eyes, it's nothing like
COBOL.

------
dmytrish
I like Plan 9 terminal somewhat, even though it's infuriatingly simplistic and
non-ergonomic:

\- the idea of the terminal as a document which can be navigated is pretty
interesting (tmux fixes this to some degree).

\- the possibility to display other types of content directly inside the
terminal window (e.g. man-pages rendered as pdf inside the terminal window),
although it was not a terminal feature, but the feature of rio.

------
jstewartmobile
I'm a big fan of the Mathematica-style console that mixes commands with media.
Being able to embed surfaces that each command could communicate with would be
fantastic. I believe Genera and Dr. Racket have similar features.

For short-lived processes, another stdio pipe pair may be sufficient (i.e.
imgin/imgout). By image, not necessarily a raster. A byte buffer with a mime
type would be more flexible (audio processing, etc.).

For long-lived processes, interactivity would be nice. Could have a
communication protocol for keystrokes/mouse while the process is active. Or
perhaps X or Wayland could be retrofitted into it some way where developers
can kill two birds with one stone.

Keeping the alignment is worthwhile, so may want to round the surface size to
some whole multiple of the character width/height.

------
btschaegg

      What do you hate about terminals?
    

Escape sequences. The current system is basically a giant bag of baggage we
inherited from ye olden days. If implemented today I'd guess it would make
much more sense to let a terminal application determine the actual key
combination pressed (such as C-Tab, for example). I'm pretty sure that
wouldn't be very easy to change, though (at least while keeping
compatibility).

Edit: To clarify: I'm referring mainly to the fact that certain key
combinations are not mapped at all, while other ones are synonyms for special
keys, i.e.: ^[ is Escape,^I is Tab etc.

cf.: [http://wiki.bash-hackers.org/scripting/terminalcodes](http://wiki.bash-
hackers.org/scripting/terminalcodes)

~~~
terminal-survey
Oh yes. We want to have an API where clients (i.e. programs running in the
terminal) can receive actual key/pointer/touch events if they choose to. The
terminal may retain control over a few crucial keysequences (similar to how
Ctrl-Alt-Del is always handled by the OS on Windows), but it has to inform the
client about that.

~~~
btschaegg
Very good to hear! That alone makes me root for you guys.

Edit: BTW: If you really get a project going, make sure to inform us how to
chip in (at least in monetary way, if nothing else. I'd like to be able to pay
anyone who tackles this a beverage of their choice ;-) ).

~~~
terminal-survey
As soon as the project is at a point where we feel comfortable showing it to a
wider audience, we'll make a proper announcement and post it to HN (among
other places).

------
TheCondor
The simplicity is great.

All the dark art and knowledge spread around is a pain, tty controls, escape
codes, etc.. I’ve used terminals for decades but where the lines are draw
between terminal, shell, tty and terminal emulator might be worth
readdressing; it’s 2017 and I will semi regularly see broken escape codes,
Eshell in Emacs doesn’t deal with the color prompt correctly as an example.

This isn’t a terminal thing exactly but I’ve got 4K displays and greater then
1080p on laptops and there is still a strong 80 column legacy. Ideally
terminal-ng would not ntroduce some future version of 80columns, I can’t think
what that would be. Perhaps somehow bridging between fixed width and non fixed
width fonts or something like that, somehow.

------
polygot
On the lines of "just working", it'd be cool to have a shell which if I could
accidentally cat a binary file and not have the shell be completely in-
operable or have to run this long archaic command to get it working again.

Maybe have something like "when I run the cat command, ignore all commands to
the terminal until cat finishes".

~~~
joombaga
What long archaic command are you running? 'clear; reset' usually does it for
me.

~~~
polygot
Sometimes clear; reset works but other times I can't see what I'm typing, and
so when I type it and hit enter it might clear the screen, sometimes it runs
the command but the bash prompt is completely messed up. I use tmux a lot, so
I usually use the reset code from this answer:
[https://unix.stackexchange.com/questions/49886/tmux-
status-b...](https://unix.stackexchange.com/questions/49886/tmux-status-bar-
corrupted-after-catting-a-binary-file-how-to-reset)

stty sane; printf '\033k%s\033\\\\\033]2;%s\007' "`basename "$SHELL"`" "`uname
-n`"; tput reset; tmux refresh

------
nathcd
I'm excited about notty [1], but I'm bummed the repo hasn't seen much action
in awhile. I think the maintainer is on the Rust core team now. Some of its
goals from the readme:

\- Full support for rich text formatting, including 24-bits of color.

\- Full and correct support for all of Unicode.

\- Lossless keyboard input.

\- Inline media content, including raster graphics and structured data.

\- Dropdown menus, tooltips, and other features which do not strictly reside
in the character grid.

\- Local echo and retained off-screen character grid state to reduce the need
for the tty to transmit data back to the terminal.

\- Subdividing the character grid to enable more complex interface layouts
without repeatedly reimplementing that logic in the controlling process.

It cites Gary Bernhardt's talk A Whole New World [2] as a major influence.
There's an open issue in the tracker for the Alacritty terminal emulator to
implement notty [3].

[1]
[https://github.com/withoutboats/notty](https://github.com/withoutboats/notty)

[2] [https://www.destroyallsoftware.com/talks/a-whole-new-
world](https://www.destroyallsoftware.com/talks/a-whole-new-world)

[3]
[https://github.com/jwilm/alacritty/issues/51](https://github.com/jwilm/alacritty/issues/51)

------
bugshideout
It would be nice if the terminal and/or shell exposed some metadata. For
example which machine and folder it is currently at.

This would allow one to have two terminals connected to two different machines
( via ssh for example ) and drag and drop files from one terminal to the
other, even if there is no route between the two hosts

It would also be nice if words or sentences in the terminal had metadata. So
one could type `ls`, see a lot files and click on obe of them to open it

~~~
O_H_E
Terminology does allow you to click a file after ls

------
dmytrish
> If you had to build one from scratch, how would you do it?

I consider Jupyter notebooks to be a fascinating evolution of the terminal
paradigm: their basic behavior is close enough to a terminal, but then you are
free to rearrange, rerun, delete cells, you can have rich visualization and
any type of browser content, you can save and restore sessions (notebooks),
share them easily, access them over the network, detach from them, etc.

------
jacques_chester
I often lose my place in a sea of similar outputs. It's infuriating that
distinguishing which command belongs to which output at which time requires me
to rely on my eyeballs.

So for example it'd be nice if my output folded up after the following command
is run. If `time` was run automatically. If I could switch on autodiffing
between runs of the same command. There are probably other such ideas.

~~~
terminal-survey
We already have a solution for this sketched out on paper (not in writing or
code yet, though). The idea is that the shell can split the terminal into
"frames", where each frame acts as its own terminal. The shell would then use
one frame per command prompt, and one frame per command (for its input and
output). The stdin/stdout that is given to the command is restricted to that
particular frame. It can then write text into that frame and move the cursor
around inside it, but cannot break out of the frame, so e.g. it cannot
overwrite the output of the previous command.

And once you have these frames, you can give them some useful properties: For
example, the shell can fold them, or apply styling hints to them (e.g. so that
a command with non-zero exit code can be highlighted with a red border or
similar).

With frames, you can also have multiple commands running in parallel. For
example, wget could signal to the shell that it will run for a while longer,
but does not require user interaction, so the shell can allocate the next
frame below the frame where wget is still running, and offer the next command
prompt.

It also means that fullscreen programs do not need to block everything: vim
may be running inside a frame that is set to the full window size, but you can
just move the keyboard focus out of this frame and scroll upwards to review
the output of a previous command while vim continues to run down below.

~~~
geokon
I think this would be pretty easy to do in eshell. Emacs gives you frames
already and supports interacting with output buffers (like compilations
errors)

Its been on my to-do list for a while. I wrote a rough outline and its similar
to what you've said as well:
[https://reddit.com/comments/6y3q4k/comment/dml16vq](https://reddit.com/comments/6y3q4k/comment/dml16vq)

------
falcolas
> What do you love about terminals?

The lack of distraction, the information density, the ability to integrate
command line tools into my workflow (yes, I have "selected text is copied to
the clipboard" enabled).

> What do you hate about terminals?

How slow the modern terminal is to transfer inputs and paint responses. I like
a lot about how iTerm2 works (its integration with tmux and sensible
keybinds), but dislike the latency even after all the recent improvements to
latency.

A much more minor gripe, but I spend a lot of time working on laptops;
acknowledging the lack of a middle mouse button (yes, I hate it too) as a
reality for most people's interactions with the terminal would be nice.

> If you had to build one from scratch, how would you do it?

First, I would "borrow" heavily from iTerm2 - its customizability and easy
defaults.

Second, I would "borrow" from the web browser rendering engines out there.
Make it simple for programs to either not care about their output at all and
let it look and and act sensibly (paragraph breaks, reflowing around spaces,
easy tables, etc), or to define a minimum amount of "styling" to create
reasonable outputs (right justifying text, centering, maximum/minimum width,
etc), or have absolute control over the positioning of every item with low
level feedback about the terminal.

This would have to be done in addition to a backwards-compatible escape-
sequence method of placing characters, of course, and couldn't be the default,
but simply making it available for new programs would be a great start.
Creating libraries for such interactions would be even better.

There is a lot of history in the terminal; it's time to learn from it and plan
for a future beyond ASCII.

------
dsr_
What I love: speed. Responsiveness. The focus on text, which is what I read
most unambiguously. Resizability and reflowing on a line-by-line basis. vim,
slrn and mutt: they all understand that a "page" is just the viewable area,
and is both important as a unit of scrolling and unimportant because it can
change at any time.

------
JdeBP
Learn from history.

Anyone who is working on improving terminals now, in the second decade of the
21st century, needs to learn from all of the work that went on in the 1970s
and 1980s addressing much the same needs and wants, let alone what has
happened since then.

Terminals got graphics capabilities. Operating systems vendors enhanced their
operating systems with abstractions with far better programmatic interfaces
like the KBD/VIO/MOU subsystems in OS/2 and the console subsystem in Windows
NT, providing mouse and keyboard input _messages_ that did not have to be
parsed and directly addressable video buffers that could be written to _and
read from_.

Real terminals and terminal emulators converged on the ECMA-48 and DEC VT
control sequences. For terminal emulators people invented remote terminal
protocols more geared towards common IBM PC compatible hardware such as AVATAR
(see FSC-0025 from 1988), and even protocols for encapsulating higher-level
things like TUI widgets.

* [https://jdebp.eu/FGA/tui-console-and-terminal-paradigms.html](https://jdebp.eu/FGA/tui-console-and-terminal-paradigms.html)

* [http://ftsc.org/docs/fsc-0025.001](http://ftsc.org/docs/fsc-0025.001)

* [http://ftsc.org/docs/fsc-0037.001](http://ftsc.org/docs/fsc-0037.001)

As for moving terminal handling out of the various operating system kernels,
people were doing that years ago too. I wrote a white paper on it for Linux in
2006, and the ideas were not new then, they having already existed in systems
like GNU Hurd and Windows NT. David Herrman, one of the systemd people, wrote
KMSCON; which, ironically given the comments about systemd on this page, was
actually included in systemd (as systemd-consoled) for about nine months until
he (with much less fanfare than accompanied the inclusion and no comment from
Lennart Poettering when asked about it) removed it again. Many people wrote
framebuffer terminal emulators, including me.

* [http://jdebp.eu./Proposals/linux-console-daemon.html](http://jdebp.eu./Proposals/linux-console-daemon.html)

* [https://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b...](https://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc)

* [https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...](https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8fQ9t9pmUuT)

* [https://github.com/systemd/systemd/pull/747](https://github.com/systemd/systemd/pull/747)

* [https://unix.stackexchange.com/a/177209/5132](https://unix.stackexchange.com/a/177209/5132)

* [http://jdebp.eu./Softwares/nosh/user-vt-screenshots.html](http://jdebp.eu./Softwares/nosh/user-vt-screenshots.html)

~~~
jstewartmobile
Your stack exchange post is _epic_. Thank you!

I have some reading to do...

~~~
JdeBP
I probably should not point to any more, then. (-:

* [https://unix.stackexchange.com/a/289871/5132](https://unix.stackexchange.com/a/289871/5132)

------
icc97
I love terminals because they have a perfect memory of all the things I've
typed. Many IDEs lack this feature. They don't keep a history of every menu
command that I've used. Shortcut keys works for simple queries, but you can
compare that to the power of repeating complex Vim commands.

I also like terminals because it feels like I'm talking to the computer more
directly, we're not going through a 3rd party.

What I don't like about terminals is that it feels like I'm in a dark tunnel
when moving around the file hierarchy, I can only see the directories directly
ahead and behind me. I guess things like FZF help to do quick searches, but
you get a much more visual picture when using window file explorers.

~~~
JdeBP
If you have never encountered an Orthodox File Manager, you should try one.
One _can_ have a hierarchical display of the file system without necessarily
using a GUI.

------
baq
i've got ~20 bashes open in various tmux configurations. the amount of times i
lost command history is infuriating (e.g. due to reboot or whatever).

context-sensitive completion (not necesarrily tab completion, mind you) is
very basic compared to IDEs.

mouse support would be good if it was actually useful. copy and paste is
useful.

zoom in/out (think c--/c-+/c-0 in browsers) would be nice sometimes,
especially when i want to copy large amounts of stuff. the fact that
copy/paste is the easiest way to transfer files over ssh is also mildly
irritating.

option to display an image or render a webpage or pdf in the terminal directly
(ala jupyter) would be nice.

~~~
terminal-survey
> i've got ~20 bashes open in various tmux configurations. the amount of times
> i lost command history is infuriating (e.g. due to reboot or whatever).

zsh does (has an option to) commit commands to the history file immediately
when you execute the command. Makes me hate bash even more when I have to use
it occasionally on a server.

~~~
chainsaw10
You can do something similar with bash. If you set PROMPT_COMMAND='history
-a', it'll append to the history file right after the command completes
(because the prompt command is run as the prompt is printed).

~~~
baq
thanks, i'm sure you've just saved a couple hours for a future me :)

------
notalex
I love that everything is doable without lifting my hand from the home row
keys, the programmability, the lack of advertisements, the consistent emacs/vi
keybindings and the low performance costs.

------
tremaali
Better integration with multiplexers like tmux and screen. Thus I get native
window boundaries for easy copy&paste with a mouse. I think iTerm2 can do this
on macOS but no Linux/BSD-one. There is terminator which has this
functionality but it does its own thing and doesn’t use a multiplexer in the
background. Essentially terminator but with tmux and Screen (both for choice
of the user…even though I think tmux is superior) in the background, so that I
can let sessions run in the background and have them available when I connect
via ssh or have them survive when the WM should crash. In addition I am a
sucker for theming. Thus easy themability and an easy way to import and export
themes. With 256 colors of course and not only 16. Otherwise I am pretty
uninagimative because most of the stuff is handled by the shell anyways and I
need to ssh into servers all the time, so for stuff like auto-completion the
terminal would need to have knowledge about the remote server as well which
would be problematic probably. Easy ways to resize - not only drag and drop
but give me a way to enter dimensions when I am on a legacy machine which has
only screen and I have to share a session with someone. And it would be neat
to save session layouts. So that the terminal opens up my last session with 10
terminals placed on the right positions on my screen (but tmux-integration
might solve that already) and maybe even remembers which servers I connected
to last in which terminal. So when I restarted my computer I open the terminal
and it starts to connect already my ssh-sessions. It is really annoying when I
restart my machine and have to reconnect to a dozen servers and arrange all
the terminals.

------
sametmax
# Portability

Having a terminal that works the same in Windows, Mac and Linux.

# Browsing UI

I have autojump and I know all the cd shenanigans, but really I want my
terminal to make it easier for me.

I want an url bar where I can see my file path and click on part of it like in
a file browser (eg: nautilusà or put an ssh address in it.

I want a back and forward button.

I want an history.

I want bookmarks.

I want to be able to right click on a path and "open url in the browser",
"unzip/untar file", "open in libre office/vlc". And I want to be able to ctrl
+ left-clik path and cd to it or xdg-open it.

This should be customizable. E.G: tilix let you enter regex that makes things
clickable. Very useful to debug tracebacks.

# Split and tabs

Most good terminals (ex: tilix, cmder) have a good split screen, quake mode,
and tab story. You can save profiles, restore them, auto run commands, etc.

It should have those, and it should be well integrated with the browsing UI.

Also changing the aspect a tab according to events. E.g: red if command return
and error code. With a special icon if you are running as root, if you ssh on
a remote computer.

# Graphical display

I want to be able to request the display of an media inside the terminal, like
an embeded image or video.

# Take control

I get that we wanted the terminal to be separated from the shell. But this
createe such an integration mismatch.

Code completion, helps, prompts... Everything is slow, hard to configure,
incomplete, unsatisfying, and not cross plateform.

Just hijack the shell and do the right thing. People that don't like it can
always use another terminal.

We don't lack configurability. We have freedom all the way with current
solutions. Keyboard only people with no windows decoration have everything
they need.

What we do lack, is a terminal for mouse lovers.

Careful with this though. Some project tried it and added a lot of graphical
things that looked cool, but were totally useless in practice.

------
gwbas1c
I'm a Mac User, and honestly I think the Mac terminal is fine and there's very
little room for improvement. But if I were to improve here's a few of the
things that I would do:

\- Make it easier to know what the current process is and kill it if it goes
haywire. An out-of-control process can trap control C and ignore it. I really
hate digging into activity monitor to kill a process when I just want to keep
the same terminal window open.

\- A better display of my current working directory, and my current git
branch. These items should be displayed at the edge of the window, not inside
the terminal itself.

\- Better view and management of my previous commands in the shell.

\- Do away with psuedo-gui terminal applications. My terminal already has a
large scroll back buffer, so we don't need applications within the terminal to
also implement scrolling and paging. I have plenty of graphical text editors
on hand. We have protocols like VNC for remote desktop control.

\- Try and see if there is a way to lower the learning curve of various
terminal applications that I may use infrequently. Often I learn how to use
terminal applications by Googling around for examples of what I am trying to
do. Perhaps something like autocomplete that we have in our modern IDEs?

\- Allow me to collapse the output of programs, just like we can collapse
comments in hacker news.

~~~
geocar
> An out-of-control process can trap control C and ignore it.

Many programs that trap SIGINT won't trap SIGQUIT so ^\ will still kill the
process. Even if they do, if ^Z works then kill -9 %1 will be good.

> A better display of my current working directory, and my current git branch.
> These items should be displayed at the edge of the window, not inside the
> terminal itself.

MY prompt has been \$ for ages, and I've many names complained about my
failing memory, but since I don't change directories often this causes me
little grief (and being in one directory means my ^R search is very useful).
Have you considered just storing this information in the title? Many virtual
terminals have an escape sequence that sets the title.

> Allow me to collapse the output of programs, just like we can collapse
> comments in hacker news.

This sounds very useful. Perhaps it would be implemented as an escape sequence
that would be marked in the prompt.

~~~
gwbas1c
What you suggest requires a significant amount of learning and relies on
hidden commands. What I'm suggesting is narrowing the use case of the terminal
and making it more user-friendly without relying on non obvious hidden tricks.

~~~
geocar
"Significant" is relative.

What I suggest is available today: and for the cost in time of reading my
message will resolve a third of your issues.

I don't know what you mean by "non obvious hidden tricks". People learn what
control-C does because they read the manual; because someone shows them.
Likewise with other keys and job control. Or the tab key. Or google. Very few
things are obvious, and you can find what they are by putting them in a room
with a potato and watching: If the potato can figure it out, then it was
obvious.

------
acrooks
Probably the most frustrating thing for me is when I’m connected to another
terminal via ssh and am typing in a command (without using autocomplete). When
I am on a poor internet connection the latency between rendering each
keystroke makes me want to throw my computer out the window.

It would be cool if the local terminal could render text at the speed of
typing and while lazily sending that back to the other machine.

~~~
adambyrtek
mosh[1] provides the buffering you're looking for and some other useful
features, at the cost of extra complexity that could lead to other issues
(e.g. no scrollback unless you use tmux as well).

[1] [https://mosh.org/](https://mosh.org/)

------
JasuM
I spent yesterday rewriting my ZSH config. A lot of the time I spent on
figuring out how to map random key combos to unused control characters. So if
I could implement both the terminal and the shell from scratch (or make a
significant addition), I would implement a scenario like this:

    
    
      1. Program informs the terminal that it supports "extended keyboard input". This would be done with an escape code, much like bracketed paste.
      2. Terminal informs the program that it is now enabled.
      3. Terminal informs the program of the initial modifier key state.
      4. When the user presses a key (including modifiers), it is sent in a format that standardizes over all the commonly used key codes. Also, if the key represents a Unicode codepoint, that is sent as well. E.g. (mod-status-at-key-press)(key-code)(utf8-char-or-null)(null-terminator).
      5. When the user releases a key, a similar message would be sent.
      6. When the program exits (or a shell runs another program), it asks the terminal to disable "extended keyboard input"

------
useranme
I love tab completion.

I hate that the terminal and the browser are two different applications.

~~~
dotancohen
They don't have to be! See: w3m and vimperator / Tridactyl

~~~
tbrock
While amazing in their own right, those aren’t examples of a web browser and
terminal becoming one application. Those are more like the interface of one
being used to manipulate the other.

I think something like hyper will get us close:
[https://hyper.is](https://hyper.is)

------
carreau
Hate the fact that you can cannot revert the termtitle to it's previous value.
A mechanisme like push/pop titles would be more convenient. Anchoring metadata
to some text (like <a> links in HTML) for terminal emulator to understand
instead of regex.

I would suggest asking authors of libraries like python_prompt_toolkit who
likely have ideas.

~~~
signa11
changing terminal-titles is just a google search away. or perhaps i am missing
something fundamental. may you please elaborate? thanks!

~~~
carreau
Yes I'm aware of the ansinescape sequence to _set_ the termtitle. But you
can't _restore_ previous termtitle without knowing them (or existing current
program). In my case with IPython I want a termtitle that say "busy" when
computation is in progress otherwise get back to it's initial value of before
starting IPython. I can't do that, because I would have to exit my IPython
shell for bash to set the previous value. So I want termtitle to technically
be a stack, on which I can push a title or pop-it without having to know what
the previous one was. See for example
[https://github.com/ipython/ipython/issues/9722](https://github.com/ipython/ipython/issues/9722),
which is recurrent. Without a getter (which is a security issue) or
introducing global state or passing the values all around you can't set a
temporary value for the title. Is that clearer ?

~~~
signa11
> Without a getter (which is a security issue) or introducing global state or
> passing the values all around you can't set a temporary value for the title.
> Is that clearer ?

yes, it is. thank you ! one simple solution might be to wrap this thingy
within an 'xprop(1)' invokation. for example, i can do the following:

    
    
        signal11@fatcat networking % xprop -id 0x2c00022 | grep WM_NAME
        WM_NAME(STRING) = "fatcat:~/source-code/c/networking"
        signal11@fatcat networking % cd ~/source-code/c/quick-hacks 
        signal11@fatcat quick-hacks % xprop -id 0x2c00022 | grep WM_NAME
        WM_NAME(STRING) = "fatcat:~/source-code/c/quick-hacks"
        signal11@fatcat quick-hacks % 
    

WM_NAME(STRING) points to the current title. and when i change the directory,
i can query the new name. fitting this mechanism for aforementioned usecase is
left as an exercise for the reader :) fwiw, the value for '-id' argument comes
from 'xwininfo(1)'

~~~
carreau
That is a nice hack thanks! Though it is not really portable to all OS, and
AFAIU not working if you ssh to a remote host ! It may give a potential way to
work partially around that limitation. I feel like an actual push/pop solution
would be better.

~~~
signa11
> ... and AFAIU not working if you ssh to a remote host !

X being a network protocol at heart, it positively is weird. i tried that
thingy on both local machine, and ssh'ed xterm to remote-machine (with X
sessions correctly forwarded locally), and it all seems to work just fine for
me.

edit-001 : these are linux machines at both ends, so, i dunno...

~~~
carreau
Yes, I'm on Mac OS so that's likely it, and the server I was trying had no X
anyway. Thanks for investigating.

------
ravenstine
I love how terminals are a universal tool that can do a lot with just the
default GNU toolset.

I hate how I can't choose the caret position with my mouse when using a
terminal emulator. Nothing seems designed to allow this. Sometimes there's too
much input and using the arrow keys or HOME/END gets tedious.

~~~
sigjuice
M-x shell in Emacs lets you use your mouse.

------
bitwize
Love: That any terminal anywhere that speaks VT100 -- including real DEC
hardware from the 70s and 80s, "communications programs" for DOS or Windows,
and modern ssh clients -- can interact with a program that also speaks VT100,
and that program thereby can produce a clean, usable, if not elaborate UI on
8-bit hardware with KiB of RAM through to 64-bit hardware with GiB of RAM and
beyond.

Hate: Mainly kids who've never seen or interacted with a dialup or other
serial connection, let alone a real hardware terminal, who think that "the
terminal" is some software construct which can (and therefore should) be
thrown out and replaced with something based on the ergonomics of a 2017
Macintosh.

------
happyhotpocket
I want a terminal that writes from the top down instead of from the bottom up.

~~~
terminal-survey
You mean that it should scroll in the opposite direction?

------
EliRivers
I'd want to be able to split it horizontally and vertically, and sub-split
those similarly, ad infinitum (see eMacs C-x 2 and C-x 3), cycling through
them with convenient copy/paste across them, with them also aware of each
other and able to pipe information to each other.

There are some that split to various degrees already; I don;t know how aware
the panes are of each other or if they'll happily pipe into each other. I'd
like to be able to run a script in one pane and have the outputs go into
different panes as directed by the script.

------
hungerstrike
I hate terminals because they're completely undiscoverable and they depend on
you typing each character exactly right or things could blow up.

Give me a good discoverable, safe UI over a terminal any day.

The only good thing about a terminal is that flexibility you get by piping
programs together. GUIs can (and do) have the same kind of flexibility but
it's not as standardized so I guess another good thing about terminals is that
there are some simple standards.

Other than that though, I'd throw away terminals forever if I could.

------
dandare
I rarely use terminals so please don't take my answer into account. Just for
the fun: I hate terminals because of the lack of discoverability. I know, it
is probably the antithesis of a terminal, something that can not be fixed
without breaking the concept of a CLI. But I really hate the lack of visual
feedback. What is the state of the system? What are my options right now? How
was my command interpreted (sometimes I have to scroll many pages up to maybe
find an error message.) Etc.

------
mmjaa
I would love for someone to produce a modern dumb terminal - akin to the
Hazeltine/VT100 systems of the past, but using modern components. It'd have
multiple serial ports, and do _nothing_ but act as a dumb terminal for a Unix
system - but it'd use modern display tech, maybe something from the elite
mechanicalkeyboards world, and so on. I'd buy one for my desktop in a
heartbeat - I'm truly sick of all the bloat required just to fire up iTerm.app
and so on.

~~~
JdeBP
Many people have already done this, such as the people who emulate DEC VTs
with arduinos and suchlike for starters.

* [https://github.com/mkschreder/avr-vt100](https://github.com/mkschreder/avr-vt100)

* [https://hackaday.io/project/13273-diy-vt100-a-miniature-hard...](https://hackaday.io/project/13273-diy-vt100-a-miniature-hardware-terminal)

* [https://hackaday.com/2010/02/24/oscilloscope-doubles-as-a-se...](https://hackaday.com/2010/02/24/oscilloscope-doubles-as-a-serial-terminal/)

* [https://tech.scargill.net/vt100-terminal-for-hc2016/](https://tech.scargill.net/vt100-terminal-for-hc2016/)

~~~
mmjaa
Quite nice .. I wonder if there'd be demand for an upscale version of these,
sort of more turnkey and less hack.

------
shortoncash
I'd like to see terminals start to mirror sort of how those interactive
programming language environments work, like where data scientists have a
notebook or workbook. Output should be collapsible, there should be snippets
on the side, and most importantly, the history should be easily manageable and
obvious to use/re-use.

It's possible a lot of terminals have the features I want already, in which
case I have a discoverable-feature problem also. Haha.

------
otron
> \- What do you hate about terminals?

Having to use the mouse to select/highlight/copy output I didn't know I was
interested in until after it'd been outputted. Being able to export/open the
currently visible history/output to an editor would be great.

> \- What do you love about terminals?

Unless I'm suddenly interested in the output of a previously run command that
can't be reproduced, I can interface with them without using the mouse at all.

------
tezza
guiding principles is that a terminal is still part of the computing ecosystem
and needs to be a well integrated companion to GUI and desktop apps running
concurrently.

so here are some suggestions off the top of my head

* padding on the left of the terminal. mouse selection from the start of the line needlessly requires precision mousing. more often than essential when attempting to select some text with the mouse, one resizes the terminal or selects a window behind the terminal frame. probably best in the gui client but perhaps some escape modes where whitespace can be hinted as not copyable

* perhaps a modes to suggest arbitrary text should not be copied to the clipboard ? say lots of banner text with a supprt url among it. selectingthe whole block only selects the useful url. ignorable by the end user of course

* mouse double-click-to-select should grow the selection. terminal output often needs to be cutnpasted into other apps

* snapshot the offscreen buffer somehow ? less somefile.txt... exit... rm somefile.txt... oops gone for all time including scrollback

* sane modern defaults. Ctrl-S freezes terminal ?!? I know this a bash thing setopt -w checkwinsize. why is this not on by default ?

------
matt_wulfeck
Call me crazy, but why does every terminal output text from the bottom and
have the cursor slowly go _up_ the screen? Why do my eyes constantly have to
track the cursor on a vertical plane? What I would like is the option for the
cursor to be at the top (the most “level” for eyes) and for all text to
waterfall down, never changing the cursor position.

------
daniel12fsp
Love: I think it's the best way to do things without GUI Hate: I cant use
mouse for copy command or edit a line

~~~
yoodenvranx
Yes, changing the cursor position with the mouse while typing a command would
be handy in some situations!

~~~
neilsimp1
I wanted to say this as well. Maybe it's blasphemy to want better mouse
support in a keyboard-driven environment, but dammit if it wouldn't be handy
to just click to a position in the line you're typing instead of slowly
crawling your way there with arrow keys.

~~~
yoodenvranx
> Maybe it's blasphemy

No, it is not blasphemy! I often find myself copying text from some non-
keyboard driven program into the command line and having the ability to change
the position of the text cursor in the command line with the mouse would be
nicer and faster because my hand is already on the mouse.

Pointing with the mouse to a specific location in the middle of a string is
always faster than doing the same thing with the keyboard (if your hand is
already on the mouse)

My favorite example is htop: Clicking on a random column header with the mouse
feels easier and faster than doing the same thing with pure keyboard
navigation.

> slowly crawling your way there with arrow keys.

In case you did not know yet: Try using ctrl + arrow keys (or ctrl + b/f) to
jump over whole words. It's still not ideal but at least it is faster than
just arrow keys.

------
yoodenvranx
I use stock bash / Konsole and I am really missing a good text reflow when
changing the size of the window.

If some command prints a line which gets wrapped because it is too long then I
wish I could un-wrap it by making the terminal window wider and forcing some
sort of re-layout.

~~~
terminal-survey
Yes, it would be nice if reflowing became more common. We are not sure if our
spec requires the terminal to support reflowing (because of the resource usage
implications), but the terminal must at least be able to announce whether it
does reflowing (and/or word wrapping).

------
mediamonster
I would like to be able to use modifier/control keys over terminal similarly
to GUIs, e.g. use Shift+arrows to mark text, impossible on current terminals.
I guess transmitting the state of all modifier keys with every keystroke would
be a simple fix.

~~~
JdeBP
It has been possible on terminals for about three decades -- since the DEC
VT220 at least.

Applications know when shift+arrow is pressed because they receive a different
control sequence. Modifier keys are reported as an extra parameter in the
control sequence for function keys and extended keys. Dickey xterm has been
doing the same since 1999. The PuTTY changelog does not indicate when it
gained this, but it has had it for years, too.

* [http://invisible-island.net/xterm/xterm.log.html#xterm_94](http://invisible-island.net/xterm/xterm.log.html#xterm_94)

And indeed you will find that TUI applications such as VIM and NeoVIM
recognize these control sequences and can distinguish arrow from shift+arrow.
See :help cursor-up and (on VIM) :help xterm-modifier-keys . (NeoVIM handles
the TUI differently, is terminfo-only, and has modifier recognition always
on.)

If some other application does not, then it is _not_ the terminals that need
fixing.

------
terminal-survey
Hi everyone, thanks a lot for the responses. Keep them coming!

As mentioned in some of my replies, we have already considered some of the
things that you mentioned (and incorporated them in our design), but your
responses show that there is still a lot more to consider.

------
sajithdilshan
Finalterm was really a promising modern terminal and had a huge potential. It
is a shame the project has been abandoned.

[https://github.com/p-e-w/finalterm](https://github.com/p-e-w/finalterm)

------
padthai
I want more interactivity with printed terminal output. Similar to copy mode
in tmux but with tools of my choice. I can type c-x e to edit input with my
$EDITOR. I want at least the same power over the output, like what I have
using acme.

------
nmstoker
Love:

1 speed (of typing/screen updates/just doing things)

2 simplicity (in general)

3 basic highlighting

Hate:

When layout gets into a terrible jumble that's hard to distinguish one thing
from another (kind of rare and is usually when using suboptimal
tools/solutions, so isn't usually a show stopper)

------
SAI_Peregrinus
I like that they're easy to automate actions with.

I hate that commands are difficult to discover.

~~~
O_H_E
Exactly what I think

------
ivanbakel
Auto-paging the output. I don't think I've ever run a command that exceeded
the height of my screen that I didn't want to scroll back through to read
anyways. Some programs get it right - `git diff` comes to mind.

------
rhizome31
I don't know if it's solvable at the terminal level only, but I would love a
terminal that never gets messed up so that I never have to type reset or close
the window and open it up again.

~~~
JdeBP
It was solved more than six years ago. The cost is that you lose support for
applications that make use of switchable 7-bit character sets: on the gripping
hand a price that most people seem willing to pay nowadays.

* [https://news.ycombinator.com/item?id=16014824](https://news.ycombinator.com/item?id=16014824)

------
nhooyr
I would love to contribute to this group. How can I get involved?

~~~
terminal-survey
We are currently doing most of the work offline, so it's difficult to
collaborate with a far-reaching network of contributors at this point.
However, if you drop me a note at < 34c3-terminal-survey at posteo dot de >, I
can put you on the list of people to ping once we have something that can be
put in front of more eyes.

------
brianon99
It is difficult to build a TUI. Just to draw several progress bars might take
a whole day to implement.

~~~
jitl
I think this issue is more one of poor modern TUI libraries than an issue with
the underlying technology.

Drawing a progress bar with OpenGL is probably more difficult than the “go to
start of line, reprint my characters” logic needed in the terminal, and yet
raster graphics APIs are undoubtedly more powerful than VT escape sequences.

------
SteveMorin
I am very interested in this, and would like to contribute. How do I get in
touch with you?

~~~
O_H_E
Answer from OP

[https://news.ycombinator.com/item?id=16015163](https://news.ycombinator.com/item?id=16015163)

------
evolighting
I always hate long output; Since there is no direct "roll up" most times

------
ajkjk
I hate Bash and all of its relatives. No language where equality is tested
with -eq should be in use in 2017; we can do so much better.

~~~
d0lph
I actually kind of like it, powershell also has -eq, and there's no chance of
mixing up assignment and equality operators.

~~~
JdeBP
You mix up the := operator with the = operator? (-:

There's no chance of mixing them up with the "test" command, note, which is
what ajkjk was talking about (even though xe erroneously attributed this to
the Bourne Again shell language), because the test command _has no_ assignment
operator. Whereas what it _does_ have is a whole bunch of syntactic gotchas
that bite people with depressing regularity.

* Miss quoting variables, and suddenly your unary operator turns into an expression that always evaluates true, because with 1 argument test merely tests whether the argument is non-blank, which a unary operator is of course.

* = is string comparison, and -eq is numeric comparison. Yes, you want the other one.

* ... but == is a non-standard bashism that does not work in scripts interpreted by /bin/sh (which is usually something like the Korn or Almquist shell) on many modern systems.

* ... and if you are using the Z, Korn, or Bourne Again shells, don't forget that you need to quote the < and > operators.

* Beware the variable whose value has a minus sign as its first character. All comparisons for safety need to be of the form x"$var" = x"something" .

~~~
d0lph
"Real" languages use "=" and "==" ;)

Was unfamiliar with the minefield of bash issues, still, I do like the -eq
operator, even if bash implements it poorly.

~~~
JdeBP
On the contrary, a real language uses .EQ. . == is for the chattering classes
who use the # sign when posting to social media. You appear to be eating
quiche. (-:

* [http://gordonbell.azurewebsites.net/ibm-026/ibm-026-ref-27.j...](http://gordonbell.azurewebsites.net/ibm-026/ibm-026-ref-27.jpg)

Rex Conn knows how a real language does relational operators.

* [https://jpsoft.com/help/conditionalexpressions.htm#r](https://jpsoft.com/help/conditionalexpressions.htm#r)

------
n34r
built-in copy-paste feature

~~~
foobarian
Copy paste with multiple buffers. I often have to copy some kind of unique ID,
then copy paste a file name to search; on a Mac I can't do this because it
doesn't support middle-button paste like X. I can do it on X but that still
only supports two buffers; would be nice to have more.

------
saulrh
If I were building a terminal from scratch... Hm.

Attempts to improve the terminal are not backwards-compatible or do not
otherwise provide a clean upgrade path. I would _love_ to use one of those
fancy graphical terms that comes up on HN every now and then, but because they
only work with a special toolchain that speaks its language and its language
only there's no way they'll ever gain critical mass and take off. Any attempt
to improve the terminal has to be something that I could switch to on a whim
and then gradually grow into.

I _really like_ the "curious fact" from higher in this thread and I think that
it's important. Whatever the solution is, I think that it'll necessarily
involve separating "business" logic from presentation logic, and giving
presentation logic to the terminal while things under the shell handle the
actual work. Right now, one of the biggest problems with writing a CLI tool is
that TUI work is a _huge pain in the ass_. It's harder to make a table in the
terminal than it is to make a table on the web! That's insane! And that
suggests a straightforward solution: Move display logic into the terminal so
that it can handle layout and rendering. And you do that the same way that
that's been done in literally every situation that's ever been done: You ship
a small program that constructs a view that can take advantage of a more
favorable execution environment.

So what does it mean to "ship a program that constructs a view"? Well, even if
your program is written in a deeply standardized, weak language (e.g. ANSI
escape codes) it's still a program. Formal languages theory, hooray. So we're
already operating in this formalism, which makes our job much easier and the
solution relatively obvious - Instead of inventing an entirely new paradigm
from the ground up we just need to jam a more powerful language into an unused
corner of the existing one.

This is where I go down the rabbit hole, because I don't know enough about the
specifics of ANSI escape sequences. My goal, essentially speaking, is to find
a set of sequences of control characters (a language) that will be ignored by
everything _except_ my New Terminal, map that set to some convenient
programming language (ideally by a trivial "prefix-identity-suffix"
construction), build a platform for building user interfaces that uses that
programming language, and then build... something that augments existing
programs with New Terminal front-ends? A lump of stuff into my shell RCs that
detects New Terminal and augments the prompt strings with New Terminal apps
that wrap the outputs of commands that look right?

Then the question is, what does my platform look like, and what convenient
programming language am I using? I'd probably go with something like js or
guile. Maybe just js so I can take advantage of extensive existing UI tooling.
I mean, if you look at this sufficiently sideways, I've essentially duplicated
the evolution of HTML+JS webapps - jam a new language (js script tags) into a
corner of the existing language (html) that will be ignored by systems that
don't understand the new thing and then implement a platform (DOM manipulation
and such) that allows the creation of fancy user interfaces (webapps) using
those tools. And really, I think that that's the clincher - that evolution
happened when client machines became powerful enough that it was useful to
move presentation logic out of the server and into the client, and that's
exactly what we need to do with terminals.

(thought: interaction. callbacks return a sequence of characters that're typed
into the terminal? so you can click on a table header and the client sorts and
re-renders the table, or you can click on a button and to run a convenient
follow-up invocation? ahhh, yeah - if the backend program (ls et al) is
transient its interactions will render commands for follow-up operations, if
it's persistent its interactions will render keystrokes for interacting with
it - you'd click on the headers in top and it'd send `p`, `t`, etc. that's
really clean.)

~~~
terminal-survey
> I would love to use one of those fancy graphical terms that comes up on HN
> every now and then

One of these (Black Screen) is among the many inspirations with which we
started.

> Any attempt to improve the terminal has to be something that I could switch
> to on a whim and then gradually grow into.

Backwards-compatibility is a hard requirement for us because of that. And oh
boy, it causes a lot of pain.

> I've essentially duplicated the evolution of HTML+JS webapps

This is a huge fear of mine. We need to find a way of opening the GUI can-of-
worms without ending up with terminals that are as bloated as contemporary web
browsers.

~~~
saulrh
> Backwards-compatibility is a hard requirement for us because of that. And oh
> boy, it causes a lot of pain.

Yeah, it's a bitch. Sorry. :( I've seen one or two "rewrite everything and
make it better enough that people switch" big-bang efforts succeed - I run
fish, 'nuff said - but this is a rather more invasive change, and it doesn't
have good fallbacks ("run bash for ten seconds").

I'm not sure there is a good solution here, not when I look at it from the
formal languages perspective. The existing language (what's relevant to
current functionality) contains nearly all sequences of elements of the
available alphabet (bytes), so anything we do will collide with _some_ thing.
Nobody was able to leave a specific exception to permit extension the way HTML
did when it decided to silently ignore unrecognized tags. Though maybe the
ANSI "application program command" escape codes might be usable? Either way,
this really seems like a question of what you're going to have to choose to
break, and that's never fun.

> This is a huge fear of mine. We need to find a way of opening the GUI can-
> of-worms without ending up with terminals that are as bloated as
> contemporary web browsers.

Pretty much. You have a titanic advantage, since you don't have to deal with
styles at all and can probably start over with a non-hierarchical layout based
on integer constraint satisfaction, but you're still stuck trying to bootstrap
a small OS/environment. Maybe "only" the size of something like a well-
designed video game modding API (factorio, kerbal space program, MMOs, etc).

Heh, emacs might be another thing you could look at, they're having some of
these issues themselves.

\------------------------------

What are the "killer apps" for these features? `cat foo.jpg` is a parlor
trick; what could you do that'd actually make me want to switch? We'd probably
be looking for small but _effective_ quality-of-life things that anyone can
use - for example, fish-shell got me with "it just works" completion and
syntax highlighting.

Hmm. Every tabular output (ps, ls, df, docker, random stuff massaged with awk
and cut) magically having sortable columns in the original data, no rerunning
the command with a different flag? Parse `--help` to make a checkbox/textbox
for each flag and a "do it" button that assembles the resulting invocation? A
standardized set of "quick invocations" that a command can give to the
terminal to be quickly invoked with something like `M-[[:digit:]]`, so that,
say, the suggestions from `command-not-found` would be a single keystroke
away, or ls could provide "cd to directory 1, 2, 3"?

------
robertelder
Love:

\- Being super productive with terminals

Hate:

\- The #1 thing by far in my book is not having better support for unicode. It
is not possible to accurately determine the width of a unicode character in
advance of printing it in the terminal. I'm aware that there are many non-
printable and control characters with unicode that don't have a 'width', but
even if you neglect those, the code that determines how wide a unicode
characer is, is terminal specific and there is no way to access the
information in advance in order to correctly align text that contains unicode,
for example with whitespace padding.

This is the kind of problem that will never bother you until it does, but then
when you do encounter it, you can beat your head against the wall for weeks
without finding a satisfactory solution, and the only thing that comes close
is something that detects aspects of your environment on every terminal out
there.

I think that improving support for unicode in terminal is something that would
be a good idea to do sooner rather than later, because unicode will only get
more important, and in the meantime, people will continue to build
abstractions upon very poor interfaces that will need to be supported in the
future. Unicode is insanely complicated, so it might be too much work to
support it fully, so one solution might be to expose some API that gives
people the power to make their own work around (for example, through access to
an snprintf like function for where n = max print width). You could add other
kinds of 'empirical test' functions that allow you to avoid the work of
actually understanding the entire unicode standard (which is still changing).

Here is a github repo that documents the unicode problems I have encountered:

[https://github.com/RobertElderSoftware/roberteldersoftwaredi...](https://github.com/RobertElderSoftware/roberteldersoftwarediff)

If I had to build one from scratch:

\- If I was building one from scratch, I would probably put a better focus on
separating out all the different components that actually make up the
'terminal'. In a typical bash session, you've got: /bin/bash, ttys, ptys, the
terminal emulator, readline (possibly), process groups, session leaders, file
descriptors, etc. This stuff is all extremely difficult to learn, and it is
very 'invisible' to the average user. Most people don't need to think about
it, but when you want to do certain kinds of automation tasks, they become
very important.

It would be cool, if each of these concepts was formalized to provide a well-
defined interface and reduce tight coupling between these components. As it
is, to an average user these concepts blur together and seem like they're 'the
same thing'.

------
tylercubell
Edit: nvm

~~~
gaius
Are you confusing the terminal and the shell there?

~~~
duiker101
Your question makes me realise I don't really know the difference and could
confuse it myself. Can quickly you clear that up for me?

~~~
gaius
Well, the terminal is a piece of software that emulates a literal terminal - a
hardware DEC VT100 for example. This was a device with a screen and a keyboard
but no CPU that sat on your desk and was connected over a serial line to a
shared computer like a VAX.

[https://en.wikipedia.org/wiki/VT100](https://en.wikipedia.org/wiki/VT100)

I actually used these, a later model, in the mid-late '90's:

[https://en.wikipedia.org/wiki/VT220](https://en.wikipedia.org/wiki/VT220)

The classic green text on black background look comes from these, tho' I
always preferred amber.

A shell is the software that reads input from the keyboard, takes some action,
which might be to run another program, and sends that output back to the
screen. The terminal emulator you are using eg. xterm or PuTTY relays from
your hardware keyboard on your PC to the shell, then renders what the shell
sends back to it. The kernel's TTY drivers are the glue between them - TTY
once meaning "teletype". In the old days between the VT on your desk and the
VAX back in the machine room there would be LAT
[https://en.wikipedia.org/wiki/Local_Area_Transport](https://en.wikipedia.org/wiki/Local_Area_Transport)

So it's a decoupled system, with the Unix philosophy of doing one thing well,
and you are free to swap the terminal you use (xterm, rxvt, whatever) and the
shell you prefer (csh, bash, zsh, etc) as you please, which you couldn't do if
it were a monolithic program like CMD.EXE.

~~~
joombaga
I wouldn't call CMD.exe monolithic, nor is it really a terminal emulator. It's
just a command line interpreter that uses the same API as any other Windows
console. I.e. bash.exe is a console application, and does not use CMD.exe.

------
logicalshift
I wish you luck because the standards are a mess, but the terminal seems to
have been ‘good enough’ for quite a long time (which is why all the standard
originate in the 1980s). I think to make a new terminal stick, it’ll need to
do something that is impossible with the current implementations rather than
just try to sort out the mess.

One possibility is graphical output. It’s not easy to write a ‘simple’
application that produces graphics right now in the same way you can write one
that outputs text to the terminal (also: ‘moving on’ from a simple design to a
more polished one generally involves rewriting the graphical portion).

A more random pet peeve: when you run a command and it goes wrong, usually the
most useful error message is the first one it displays, but the terminal will
scroll to display the last errors which are usually less interesting. A
‘workbook’ style terminal (like you might see in a CAS) might ameliorate this
problem? It also helps with a command outputting a giant pile of garbage
because a parameter was wrong, as well as the issue where if you’re running
something like a compilation job over and over to fix errors it’s hard to tell
which messages were from the most recent vs the previous command.

