Live data from Hacker News

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

news.ycombinator.com

61–70 of 204 posts

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

#61
post #58

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…

Your stack exchange post is epic. Thank you!

I have some reading to do...

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

#62
post #36

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 require…

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/

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

#63
post #8

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 i…

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.

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

#64
post #42
post #38

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

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

#65
post #55
post #45

Earlier quoted context omitted.

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 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 int…

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.

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

#66
post #8

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 i…

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

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

Enjoy.

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

#67
post #34

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…

"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

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

#68

  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

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

#69
post #58

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…

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

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

#70
post #34

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…

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

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.

Post reply on HN