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

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.

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.

Very interesting! Thanks for the explanation

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

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.