4 ms·

> Escape is though - and has proven to be quite > an important control character too Making the ASCII escape character the same as the keyboard escape key is

> Escape is though - and has proven to be quite > an important control character too Making the ASCII escape character the same as the keyboard escape key is one of the most annoying things in the history of terminals. It means terminal apps can't just react to your escape key directly; in theory they have to wait for the next character, to see if it's part of an escape sequence (because eg. arrow keys are escape sequences). This is why so many curses-based terminal apps don't use escape to go back a level or close a window, even though GUI apps do it all the time. Too hard to make it work predictably.

laumars 8y ago
You say that but it's actually a really easy problem to work around because the timing differences between an escape sequence and an escape key being pressed followed by any other character are vastly different. So you just look at the pause after the escape key to judge if it's an escape sequence or not (only needs to be a fraction of a second too). In fact in the terminal stuff I've written in Go, escape sequences end up being picked up as one array even though the TTY is set to be unbuffered just because of the time the code takes to itterate through the STDIN read loop. So didn't even need to write any fancy timing logic for the terminal stuff I've written in Go. Sure, in some rare edge cases you might have a situation when connecting to a remote TTY over a laggy network connection will cause the escape sequence to fail because of timing issues, but that's less of an issue these days and I think the terminal would be pretty unusable by that stage anyway. > This is why so many curses-based terminal apps don't use escape to go back a level or close a window, even though GUI apps do it all the time. Too hard to make it work predictably. Escape is used all the time in terminal apps though. Readline uses it when you have vim mode enabled (which means Bash also supports it), Vi obviously uses it heavily. Tmux, top, cfdisk all support escape. But most importantly ncurses stuff (eg dialog) does too. So I think what you're talking about there is more of a UI design decision rather than terminal programs not being able to do it. Thinking back, I don't really recall escape being a common navigation idiom until it became popular on the web. Your typical 90s WIMP UI (eg Windows 9x, MacOS 7+) wasn't escape heavy either (or at least it wasn't a common way to navigate as I recall). Sure you'd use it on model dialogs (eg file->open) but really very little else. So terminal software - being much older, generally speaking - never had that convention either. In fact it wasn't even that common on the web until model dialogs became all the rage so people used to use the back button heavily (and hence why GUI file managers have forwards and backwards buttons in them - but that's a whole other tangent). To be honest though, I much prefer the terminal approach anyway. Escaping out of screens feels very crude and the terminal approach for multiple "screens" of data was to use function keys or control sequences to precisely navigate from one screen to another. Or in the case of ncurses UIs, optionally using arrow keys to highlight the option you want. Personally I find the function key kind of workflow far easier to navigate than escaping stuff all the time but I guess it's what you're used to. In any case, terminal apps don't need to wait for the next character to determine whether the user is pressing [esc] or [-->] (with the terminal emulator transmitting CSI+n+C). You just look at the timings instead.
- Dylan16807 8y ago
  Sending key codes in a batch should not cause their interpretation to be changed! It might be the least bad solution right now, but it's not good.
  - laumars 8y ago
    From an idealistic point of view I agree, but both ASCII and ANSI escape codes predate the kind of terminal UIs we are discussing here and thus things just organically evolved that way. You only have to look at the mess that is applications built on top of Electron using HTML, CSS, JS transpilers etc to see how we’ve not learned our lesson about evolved technologies becoming de facto. There’s plenty wrong with writing UIs in the terminal due to the age of their design but in regards to the argument raised by the GP, detecting the escape key is one of the lesser painful anti-patterns in that area and thus a great many tools do use the escape key.

laumars 8y ago

You say that but it's actually a really easy problem to work around because the timing differences between an escape sequence and an escape key being pressed followed by any other character are vastly different. So you just look at the pause after the escape key to judge if it's an escape sequence or not (only needs to be a fraction of a second too). In fact in the terminal stuff I've written in Go, escape sequences end up being picked up as one array even though the TTY is set to be unbuffered just because of the time the code takes to itterate through the STDIN read loop. So didn't even need to write any fancy timing logic for the terminal stuff I've written in Go. Sure, in some rare edge cases you might have a situation when connecting to a remote TTY over a laggy network connection will cause the escape sequence to fail because of timing issues, but that's less of an issue these days and I think the terminal would be pretty unusable by that stage anyway. > This is why so many curses-based terminal apps don't use escape to go back a level or close a window, even though GUI apps do it all the time. Too hard to make it work predictably. Escape is used all the time in terminal apps though. Readline uses it when you have vim mode enabled (which means Bash also supports it), Vi obviously uses it heavily. Tmux, top, cfdisk all support escape. But most importantly ncurses stuff (eg dialog) does too. So I think what you're talking about there is more of a UI design decision rather than terminal programs not being able to do it. Thinking back, I don't really recall escape being a common navigation idiom until it became popular on the web. Your typical 90s WIMP UI (eg Windows 9x, MacOS 7+) wasn't escape heavy either (or at least it wasn't a common way to navigate as I recall). Sure you'd use it on model dialogs (eg file->open) but really very little else. So terminal software - being much older, generally speaking - never had that convention either. In fact it wasn't even that common on the web until model dialogs became all the rage so people used to use the back button heavily (and hence why GUI file managers have forwards and backwards buttons in them - but that's a whole other tangent). To be honest though, I much prefer the terminal approach anyway. Escaping out of screens feels very crude and the terminal approach for multiple "screens" of data was to use function keys or control sequences to precisely navigate from one screen to another. Or in the case of ncurses UIs, optionally using arrow keys to highlight the option you want. Personally I find the function key kind of workflow far easier to navigate than escaping stuff all the time but I guess it's what you're used to. In any case, terminal apps don't need to wait for the next character to determine whether the user is pressing [esc] or [-->] (with the terminal emulator transmitting CSI+n+C). You just look at the timings instead.

Dylan16807 8y ago
Sending key codes in a batch should not cause their interpretation to be changed! It might be the least bad solution right now, but it's not good.
- laumars 8y ago
  From an idealistic point of view I agree, but both ASCII and ANSI escape codes predate the kind of terminal UIs we are discussing here and thus things just organically evolved that way. You only have to look at the mess that is applications built on top of Electron using HTML, CSS, JS transpilers etc to see how we’ve not learned our lesson about evolved technologies becoming de facto. There’s plenty wrong with writing UIs in the terminal due to the age of their design but in regards to the argument raised by the GP, detecting the escape key is one of the lesser painful anti-patterns in that area and thus a great many tools do use the escape key.