Live data from Hacker News

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

news.ycombinator.com

131–140 of 204 posts

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

#131
post #57

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…

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

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

#132
post #96

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.

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

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

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

#134

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

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

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

#135
post #122

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

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

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

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

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

#137
post #122

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

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.

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

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

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

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

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

#140

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

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

Post reply on HN