Ask HN: What do you love/hate about terminals? Would you change them? | Hacker News Reader

Ask HN: What do you love/hate about terminals? Would you change them?

I'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.

I'm posting this from 34C3, where I'm asking people the same questions:

- What do you love about terminals?

- What do you hate about terminals?

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

If you do not wish to answer in public, you can also write a mail to 34c3-terminal-survey at posteo dot de.

[I'm posting from a throwaway account because my Github links to the work that we have started on this, and I don't want to bias the survey by having you look at it before answering.]

View on HN

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.

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.)

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.

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 :)

> 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".

FWIW, I also find myself wanting this.

Sometimes you forget. Or sometimes a command generates an unexpectedly large amount of output. This is a tool that I use every day. Usability should be a priority. Even if there is a more complex way of doing something, it is better if there is a simple way.

Crank up NeoVIM. Run :terminal . Use those commands and break out of terminal mode, possibly with a long running command still running, with the mouse or with Control+\ Control+N . Explore the searchability and the use of :set scrollback .

Is that approximately the sort of thing that you are looking for?

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.

Text mode is handy because it works transparently over SSH.

Sounds like a solvable problem, right? The same protocol that allows the shell to communicate with the terminal window can be used over SSH.

I don't know much about how SSH works, but there has to be a way to communicate between the daemon and the client that both support this protocol and send the data separate from the screen content? In the typical case where you SSH from your own terminal window your ssh client just forwards the connection to your terminal window and done.

It's not like anything stops working when this stuff isn't there. It's just like colors in that respect.

>Modern IDEs can tell me exactly what can follow after a certain piece of text

I don't think that's computable in a terminal.

It could be, if there was a standard format or protocol by which a shell can ask a command what flags/options make sense in what context.

A bit like how man pages are a standard format for static docs, every tool could ship "autocomplete files" which tell a shell how to build the autocomplete. These files could even contain runnable code (in sh or something) without an additional security risk - after all, they came with a program that you're about to run :-)

I'm sure there's all kinds of challenges with this when you go deeper, but when even a relatively lightweight tool like VS Code can give me perfect C# IntelliSense on every major OS, I find it a bit abysmal that unzipping a file from the terminal is non-trivial.

This is pretty much how bash completion works...

That's not exact, it only works when certain conventions are followed, which is the situation we have now and will always have because unlike IDEs which typically autocomplete context free (or nearly so) languages your asking for auto completion to be done on what is essentially a very complex recursive language.

Also zip sucks, use tar or cpio.

This. I would love to be able to type "[command] --[tab]" and have it list all the options, and/or common options, so when I'm learning 'tar' I don't have to start typing, realize I've forgotten the command, and then have to go use man or --help or go Google it.

Have you checked out ZSH? It can do this nicely.

zsh via its ultra-tunable completions can do only 1st part of op's request i.e command option completion, but not the second part i think...

for example, i do the following:

    anupam@virat ~ % autoload -Uz compinit
    anupam@virat ~ % compinit
    anupam@virat ~ % git a<TAB>
    add        -- add file contents to index
    am         -- apply patches from a mailbox
    apply      -- apply patch to files and/or to index
    archimport -- import an Arch repository into git
    archive    -- create archive of files from named tree

edit-001: added trivial example.

My (pretty much vanilla) zsh works quite nicely

https://i.imgur.com/SZqu63p.png

I'm not sure it covers all of the obscure commands you can think of, but 99% of the time it's great.

As far as I can remember the only standard command I use and that my ZSH has trouble with is `dd`. Luckily, its arguments aren't that complicated.

My zsh autocompletion list for git add actually contains the stageable files. I don't know if this is stock zsh behaviour or related to my prezto https://github.com/sorin-ionescu/prezto config but it can be done

Edit: looks like it might be stock behaviour https://github.com/zsh-users/zsh/blob/master/Completion/Unix...

Weird. I'm using Zsh and I swear I've tried that before with nothing happening, but it does actually work. Thanks!

Pretty much any modern shell (bash, zsh, fish, etc) provides command line completion.

If you really think the completion in current shells is the best there can be then I think you lack imagination.

I don't want remembered commands, I want the terminal to tell me what stuff means. I want it to tell me what makes sense in which context. Like the IntelliSense when coding Java or C#. Docs at your fingertips, all relevant options (and none else) available, etc. This is incomparable to the kind of autocomplete any shell I've seen to date has. Zsh is a nice step in the right direction but it's still shit.

fish shell does exactly what you say, out of the box. c/p below:

  ~/.l/share: tar --<tab>                                                               
  --absolute-paths               (Don't strip leading /)
  --after-date                   (Only store newer files)
  --append                       (Append files to archive)
  --atime-preserve               (Keep access time)
  …and 58 more rows

As others have mentioned, zsh can be tuned to perform similarly. fish is nice in that if you don't have explicit completions for options set up it actually parses man pages.

Of course you could always do better, but the specific feature mentioned in the parent comment (completing flags for "tar" instead of checking the man page) has been around for ages.

Regarding contextual analysis, the fundamental problem is that command execution relies on a list of strings (argv) with no types or meaning. Each command is responsible for parsing its own arguments, either manually or using a shared library (e.g. getopt). This provides loose coupling and flexibility, but makes introspection really difficult, and features like completions become an afterthought reimplemented in every shell either by special cases for each command or hacks like parsing help messages.

> 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.

> 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.

> 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.

>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.

I see how that would easily break scripts. Not in theory no, but in practice. The instant developers gets a choice on this they will develop for their needs and break others.

It breaks what I as a user expects from a terminal and if such a terminal was launched today I don't believe anyone would use it. Not because the idea is bad but because the users of a terminal have a very confined idea of how the communication is supposed to work.

It absolutely must work the same over ssh on my phone or my fridge as on my workstation (regardless of OS). KISS.

Now that doesn't mean we can innovate or improve things, but it must be done without breaking expectations and it must be compatible with the mindset of today or I don't believe anyone will pick it up.

Presumably it would be in the same fashion that file dialogs are generated; you defer the actual selection to some OS-provided library function, and just accept a standardized output (some FileObject construct). So the terminal would provide this file selector, based on context: a script would take it as the filename itself, the interactive shell would provide the file dialog, etc.

Terminal Programs are already outputting differently based on context (ie ls to a pipe vs screen), so supporting interactive and scripting is hardly a novel idea in the space; its just that the interactive support hasn't fundamentally improved in decades

Are you referring to The NeXT Introduction - October 12, 1988[0]?

[0] https://www.youtube.com/watch?v=92NNyd3m79I

Yes I am, for a pin-point location you might want to look at the second video on http://www.computerhistory.org/atchm/the-deep-history-of-you...

You do not need to watch the whole 2 hours, only 20-25 mins where Steve Jobs introduces Nextstep and demonstrates it on a Next machine.

check out black-screen terminal emulator

check out black-screen terminal emulator for IDE style auto completion

You might be interested in this: https://news.ycombinator.com/item?id=15138613

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.

> At first I would state one curious fact: [...]

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

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.

"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.

There are already terminals and cat implementations that can display 24-bit images just fine in the terminal, by using special escape codes that each encode a pixel. No changes to the IO model needed.

https://github.com/saitoha/PySixel/blob/master/README.rst

Sure - this is what I mean by "protocol". In the case of the image format you linked even cat does work, because the image format contains pre-rendered escape sequences. This does not work in general (e.g. for JPEG or other formats) - where you need a program that does the transformation into escape sequences.

While plain `cat` does not work, using escape sequences and providing support in the terminal emulator allows already to display images inline. See the iTerm2 implementation here: https://www.iterm2.com/documentation-images.html

Making plain `cat` work too should not be too big of a problem with some small support from the running shell. iTerm2 also knows when a command is starting to run/exits, parsing the output it retrieved from STDOUT in between by matching it against some magic numbers and displaying the content accordingly is not too difficult.

Then it's not cat anymore. The purpose of cat is to output the inputs unchanged and concatenated. If you need magic, that's a task for another program.

`cat` is doing exactly that. It is up to another program, namely the terminal emulator to interpret its output.

The terminal emulator does not (and should not, according to my strong opinion) interpret the output of different programs differently.

In fact it's not currently technically possible for a terminal emulator to know which program is writing into it. It maybe many programs simulatenously, or it may be the kernel asynchronously, etc... If you want to change that you would have to make the architecture tremendously more complicated and less flexible.

And the same goes for shells. You don't want to complicate the architecture just so that a lawyer could attest you that "it was cat" who drew the image und some weird interpretation. Nothing would be gained, and nobody would be able to understand what's happening anymore.

> "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.

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).

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.

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)?

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.

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

> 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.

Enlightenment's Terminology has this. It's a separate command "tycat", but yeah, it can display images and videos in the terminal.

They also have "tyls", which will create little thumbnails when listing picture or video files and then you can click on the thumbnails to show the full thing.

https://www.enlightenment.org/about-terminology

So basically you just want an Xterminal. This is pretty much exactly why X exists...

> - 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.

Couldn't agree more with you. Simplicity is the key to a sane world. I haven't had any problems with colors or fonts with st since I dropped urxvt in favor of the former. It is also harmful to assume that bash is always present, or worst, that it is the default shell; I've spent a reasonable amount of time learning how to effectively write portable shell scripts that can run in any Unix-like system, because portability is important. Bash is huge, and that makes it more prone to error and bugs, not to mention slower, the perfect balance I've found between speed and interactivity is mksh, I know dash can be faster, but it only works for scripting, as an interactive shell it sucks, and that's ok.

>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.)

>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).

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

Thanks!

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.

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

I don't really care about how they tried to solve it, I'm just glad they addressed it.

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

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

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.

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.

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

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.)

well, would you look at that! -n is great.

> sed -n 16p filename > newfile

where 16 is the line number.. this is it! That's quite handy.

> ... 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...

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

My ideal modern terminal would be pretty much a reimplementation of Symbolics' Listener: 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

- 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.

looks like powershell stole at least some of those ideas, which makes sense given what it is.

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.

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.

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.

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.

  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

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.

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 ;-) ).

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).

So basically, you hate ASCII and Unicode.

Not really, just the way that keyboard input is mapped to a charset (like ANSI or Unicode). A keyboard is not a device that is 100% compatible with any character set (mainly because it is an array of keys that have an arbitrary meaning in a charset).

The current terminal architecture enforces any application to adopt its mapping of key combination to code points, which doesn't really make sense, at least from an input perspective (think of binding C-Tab in Vim to something: You can't, because the terminal knows no representation for it).

What would make sense OTOH is for the translation to happen in the application itself -- and maybe having a common API that makes the default mapping easy to use.

If I read [1] correctly, that's basically the same idea -- introduce a new API with which an application can determine which buttons were actually pressed as opposed to just reacting to an ANSI control signal that could've been produced in multiple ways.

Peripherals have the same problem, by the way: The USB HID for example can't send code points to the computer, but can only produce key codes, which are then interpreted by the keyboard driver. Sadly, this means that I can't tell my Ergodox keyboard to send an `ä` to the computer directly, only the combination that would produce this character if the right language has been selected.

Edit: Also, to quote the Plain White T's: Hate is a strong word... ¯\_(ツ)_/¯

[1]: https://news.ycombinator.com/item?id=16015036

What you say about keyboards is true for PC keyboards, but was not always, historically, the case. Terminals always sent the ASCII code of the pressed key(s), and especially in early terminals, all CTRL really did was to mask off the highest bits of the transmitted code leaving a value between 0-31 -- the ASCII control range. That's why ^I is TAB and ^[ is escape.

If we implemented what you proposed, terminal emulators wouldn't be terminal emulators anymore -- they'd be some sort of generic input and output framework. While we're at it, why don't we include another API to take advantage of the high-color framebuffer displays most modern computers enjoy rather than just displaying a grid of fixed-width text characters. Oh look, we've just reinvented X11. Again (see: Wayland).

Or how about no, because it's yet another library dependency in what should be a straightforward terminal program, and the whole solution breaks when the program is talking to a real live terminal (as Linux programs can still actually do) because there is no "underlying key event" from a terminal. And if you are assuming an environment like X11 or Wayland, just write an X11 or Wayland program and be done with it. (Both vim and Emacs have taken this approach, and AFAIK support keybindings of the type you describe while running in graphical mode.)

As far as I can see it, we basically agree on everything discussed so far, except for the idea that it might be worth to try and fix some historical shortcomings.

While that's a worthwhile discussion to have and I see the difficulties in maintaining compatibility (see my original post), I'd say that arguing either way goes somewhat against the premise of this thread.

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.

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".

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

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...

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

Our draft already contains a command for "set terminal into ignore-escape-sequences mode". I added that last week when someone showed how to hide malicious code in "git diff" by using specifically crafted control sequences.

Two errors there.

1. "reset" is six keypresses long, seven if you use the Control+J approach (although terminal control codes do not affect the line discipline and won't by themselves upset the newline settings of the line discipline in the first place), and not really archaic or long. On many terminal emulators, there is a menu option on the emulator that does the very same thing.

2. The mosh people addressed this problem years ago, and made a lot of noise about doing so. It's mainly a matter of just not supporting the old ISO/IEC 2022 control sequences for changing 7-bit character sets. See https://news.ycombinator.com/item?id=13904008 for more.

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.

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

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

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

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

Terminology does allow you to click a file after ls

> 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.

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.

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.

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

I hadn't thought about something like this but it sounds amazing. I wonder if there's some sort of existing terminal/shell combo that can do this, at least through plugins.

Ilya Sher's Next Generation Shell aims to allow running multiple commands in parallel, with each command's output collected and displayed below that command.

* https://github.com/ilyash/ngs

> 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.

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

* http://ftsc.org/docs/fsc-0025.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

* https://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b...

* https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...

* https://github.com/systemd/systemd/pull/747

* https://unix.stackexchange.com/a/177209/5132

* http://jdebp.eu./Softwares/nosh/user-vt-screenshots.html

Your stack exchange post is epic. Thank you!

I have some reading to do...

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

* https://unix.stackexchange.com/a/289871/5132

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.

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.

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.

> 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.

I use an eternal history setup for bash, with bash session tags that let me sort history by tag for correct backward-search behavior.

(edit) Not to imply this functionality belongs to a terminal, far from it. But it's nice to have access to 2 years of shell commands :-)

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).

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

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.

# 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.

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.

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.

> 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.

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.

"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.

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.

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/

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"

I love tab completion.

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

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

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

shivers thank god they are two different applications.

And i'd prefer the two very different functions remain separate programs, i don't need my terminal client to be vulnerable for browser issues (or vice versa).

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

I'm curious, why would you want that? What is the benefit of having these two applications with separate concerns becoming one?

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.

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

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, 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 ?

> 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)'

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.

> ... 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...

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

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.

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

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.

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

You mean that it should scroll in the opposite direction?

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.

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.

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.

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://hackaday.io/project/13273-diy-vt100-a-miniature-hard...

* https://hackaday.com/2010/02/24/oscilloscope-doubles-as-a-se...

* https://tech.scargill.net/vt100-terminal-for-hc2016/

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

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.

> - 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.

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 ?

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.

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

That would only need a modification to the GNU readline library (if it doesn't already support it.)

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

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.

> 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.

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.

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).

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.

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

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.

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.

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

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.

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)

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

I hate that commands are difficult to discover.

Exactly what I think

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.

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.

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

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

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.

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

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.

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

Answer from OP

https://news.ycombinator.com/item?id=16015163

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

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.

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

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" .

"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.

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...

Rex Conn knows how a real language does relational operators.

* https://jpsoft.com/help/conditionalexpressions.htm#r

Totally agree, it is just unintuitive for anyone who just knows any type of a "normal" language

built-in copy-paste feature

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.

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.)

> 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.

> 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 something. 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"?

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...

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'.

Edit: nvm

Are you confusing the terminal and the shell there?

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?

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

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

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

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.

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.

Very interesting! Thanks for the explanation

Frankly speaking, your love, hate and suggestion have nothing to do with the terminal, but everything to do with the shell and userland.

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.

Totally agree. That's the idea of a terminal. There are times and places for other more featureful technologies as well, but these are, well, not terminals...

But still, do you have any "small" things that could be improved. There was someone suggesting that any keypresses / releases should be sent (also Shift/Ctrl etc). I like that to some extent, but I'm afraid it already breaks a lot of usecases.

Maybe the question should be more like, as a DevOp / Sysadmin / Developer, what does your ideal environment look like? And the answers will be as varied as the people asked.

* https://news.ycombinator.com/item?id=8595907

* https://news.ycombinator.com/item?id=16014573

Enjoy.

> 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.

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.

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.

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.

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.

Reply on news.ycombinator.com