Hacker News new | ask | show | jobs
by beefhash 3094 days ago
> - 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.

2 comments

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

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.