Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 204 posts

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

#51

Post by yoodenvranx »

neilsimp1 wrote: post #44
yoodenvranx wrote: post #27

Earlier quoted context omitted.

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.

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

#52

Post by jstimpfle »

ansible wrote: 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.

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

#53

Post by logicalshift »

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

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

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

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

#55

Post by mtrycz2 »

signa11 wrote: post #45
stevewillows wrote: post #40

Earlier quoted context omitted.

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

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

#56

Post by jstewartmobile »

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

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

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

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

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

#57

Post by baq »

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

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

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

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

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

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

#58

Post by JdeBP »

Learn from history.

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

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

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

* https://jdebp.eu/FGA/tui-console-and-terminal-paradigms.html

* 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

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

#59

Post by adambyrtek »

ropeladder wrote: post #28
skrebbel wrote: post #16

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…

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.

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

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

#60

Post by asgeir »

signa11 wrote: post #45
stevewillows wrote: post #40

Earlier quoted context omitted.

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

Post reply on HN