8 ms·

Fix Terminals

135 points by smartmic 6y ago

tyingq 6y ago
Typing "echo <ctrl-v><esc>c<return>" to fix a garbled Vt100 like terminal remains embedded in my brain from long ago. Despite simpler things like "stty sane" existing. I don't know if maybe I was an admin on some box with a wonky stty, or why that's in my brain.
- haecceity 6y ago
  Is <ctrl-v><esc> same as \x1b? Why are they same?
  - tyingq 6y ago
    Yes, 0x1b is an ascii <esc>. <ctrl-v> essentially means "insert the next key I press verbatim". So, like in Vim, <esc> would switch modes, unless you press <ctrl-v> first. Helpful if you're trying to insert a control character into a file, or echo a literal <ctrl-c> etc.
    - haecceity 6y ago
      Does the terminal emulator handle the ctrl-v or shell or somewhere in kernel?
      - deleted 6y ago
        [deleted]
      - jclulow 6y ago
        Whichever facility receives and processes the inbound keystrokes. In simple software that uses the terminal in canonical mode, the line discipline (usually in the kernel) handles the batching up of bytes into lines before passing them onto the software, and thus provides the line editing. In more complex software that puts the terminal into raw mode, it's then handled in that software; e.g., by libedit or readline or some bespoke terminal handling.
- VMG 6y ago
  I just type `reset` (maybe it's a zsh thing)
  - tyingq 6y ago
    I don't remember, though I worked on a lot of oddball stuff. 3B2, Pyramid OSX, DGUX, etc.
- drran 6y ago
  Why not just `clear` or `reset` terminal?
  - tyingq 6y ago
    Wish I could remember why not :). I know now, but the muscle memory sticks.
dan-robertson 6y ago
Personally I feel like the fix for terminals is not to use them. Emacs for example has a lot of effort put into supporting various different terminals and efficiently displaying text. Some xterm-specific support is for many colours, mouse support, and the control codes to ask xterm to send more precise key escape sequences so TAB and C-i aren’t confused for example. It also has a gui which doesn’t need to pile on layers of hacks and works great so long as you don’t need to go through a terminal (eg running over ssh.) And yet it is still straddled with backwards compatibility from those days (some users expect TAB and C-i to do the same thing.) To me it feels silly to put a lot of effort into supporting things better in terminal emulators because they are not as flexible as actual user interfaces and I think the main reasons we still have them are historical. Aside: I’d also like to see a command line shell which runs outside the terminal emulator rather than inside it.
- nixpulvis 6y ago
  All the issues are just matters of backwards compatibility at this point. As far as I'm concerned, we'll always need a text based REPL oriented interface.
- coliveira 6y ago
  You can also learn to use the terminal. This can clear many of the problems that you would otherwise have by thinking that the terminal is just another windows/macos application.
  - dan-robertson 6y ago
    I don’t know how to respond to this as you seem to just think I’m an idiot who doesn’t know how to use computers. The problem with using a terminal is that control of it is distributed between a few things the user can control and the escape sequences (or just output) produced by the shell and any processes that run in it. These may end up conflicting with each other leaving your terminal in a bad state or you may just get broken output (ever tried piping pv something | ... | less?). One way to regain some control is with something like tmux but this can become unwieldy (and heaven forfend it sees a multibyte Unicode character—terminal emulators don’t really have a way to communicate with applications about how wide a character is going to be when drawn) I think a few things get conflated because there are few text-centric or command-line user interfaces. I put it to you that it is possible to have good composable text-centric user interfaces that don’t rely on pretending to be a VT100 or an ancient single-byte-stream-with-control-sequences protocol.
deleted 6y ago
[deleted]
vemv 6y ago
While I don't enjoy being negative, this doesn't sound like a solution that would work - it essentially needs 'boiling the ocean' i.e. convincing everyone else. (That's literally the plan described in the article) The first paragraphs of https://clojure.org/community/etiquette https://clojure.org/community/etiquette nail it: the software community is about making. If you want something done, make it. How would a "maker-driven" solution look like in this domain? For example: - make a terminal emulator that accepts the devised keybinding system - make at least one popular program (e.g. Emacs) play fine with said terminal - promote that combination, showing the world how the technology can in fact work. Word of mouth would do the rest.
- aurelian15 6y ago
  You are certainly not wrong. In this specific case however, I'd like to point out that the author, leonerd, has been busily working on "making stuff" to this end for years now. They are the lead author of libvterm, a popular modular terminal emulator library that is for example used in neovim and emacs-libvterm. They have also been working on libtermkey, a library that accepts input from the divised keybinding system, now part of libtickit mentioned in the post.
- Scarbutt 6y ago
  like this? https://iterm2.com/documentation-csiu.html https://iterm2.com/documentation-csiu.html
  - mixmastamyk 6y ago
    Any other terminals support it?
  - enriquto 6y ago
    seems cool but it is macOS-only
  - hultner 6y ago
    Cool, so heat vemv requested already exists with iTerm and neovim.
gumby 6y ago
Excellent satire!
ashton314 6y ago
The conflation of various control characters, i.e. `Ctrl-i` and `Ctrl-I`, was one of the primary reasons that convinced me to try using Emacs outside of the terminal. I'm glad I switched. Now I can make much more ergonomic keybindings.
aidenn0 6y ago
I agree that using the 8-bit CSI to eliminate the escape ambiguity would be great. The rest I'm a bit "meh" on. In particular I use C-S as the modifier for my terminal shortcuts, so if the terminal could detect it I'd be looking for yet another set of bindings that no terminal programs will ever use.
- alpaca128 6y ago
  The only decent solution in my view would be a new, separate kind of terminal spec, maybe even completely focused at terminal emulators. It could make sense to handle input better(maybe even with keyup/keydown events) and maybe display images in a non-hacky way(it can already be done via w3m...kind of). Changing the existing standards just won't work as it would break a ton of programs, although if I'm being honest - while I like the idea of such a terminal rework - I don't know if it can be done nowadays without it opening the flood gates by developers who just can't restrain themselves from adding so many features it might as well be a new browser engine. And either way I don't think it's worth the effort as those input limitations only affect a few specific situations. I use hundreds of custom keybindings in Vim and so far the only obstacle I encountered was the `Tab` & `Ctrl-i` overlap. If I need to hold down more than one modifier I did something wrong anyway.
  - aumerle 6y ago
    https://sw.kovidgoyal.net/kitty/keyboard-protocol.html https://sw.kovidgoyal.net/kitty/keyboard-protocol.html https://sw.kovidgoyal.net/kitty/graphics-protocol.html https://sw.kovidgoyal.net/kitty/graphics-protocol.html
    - alpaca128 6y ago
      Looks great, the only gripe I have with Kitty is how slow it is, especially on startup. I guess mostly because the combination of Python and tons of features has a negative effect in this area. In fact that was the only reason I switched away from it despite its great font ligature support; I use terminals a lot and so the constant delay when opening a new window was a bit much. However I like those modernised protocols and it would be neat to have widespread support for it.
mixmastamyk 6y ago
I didn't fully understand the spec, it got hard to read towards the end. Is this is supported by curses/terminfo?
Animats 6y ago
You can work directly at the keycode level, and watch the key up/down events. Many programs do, especially games.
- duskwuff 6y ago
  That doesn't work in a terminal. Terminals can operate over many different channels which don't pass through raw keyboard events (like SSH), or which don't have them at all (like serial links).
alanbernstein 6y ago
Can anyone point me to an article that explains why we are still stuck with these standards from the 1970s? I understand backward compatibility can be important, but I don't quite understand why terminal standards are the ONE thing in the computing world that just can not move into the future.
- opk 6y ago
  Just be glad that it didn't go the other way with terminals being full HTML 5 and having to watch advert videos between command invocations.
  - m1gu3l 6y ago
    i think a few years ago someone tried to get me to try some terminal app that was Electron based. not AS bad but still... barf.
- deleted 6y ago
  [deleted]
- enriquto 6y ago
  > just can not move into the future. It can. How would you like them to move into the future? It's not as if there's been no recent evolution in terminal emulators. Notice that evolving into the future and using old ideas are not incompatible. Modern cryptography still uses Euclid's algorithm from more than two millennia ago.
  - AnIdiotOnTheNet 6y ago
    > How would you like them to move into the future? For starters: stop using in-band signaling.
    - derefr 6y ago
      That's a big "for starters." In-band signaling — or rather, in-band markup — is a big part of what makes a "terminal" (i.e. a TTY/PTY device) semantically a "terminal": a hybrid character-grid / event-log that works both as a sink for streamed-in text, and as a "plotter" for making line-printer art. A device that both streams out as, effectively, an input-event log (where this log can be captured for replay, as with script(1) or most logging systems); but which also maintains a notion of being a ring-buffer "containing" a rectangularly-bounded volume of text (and control-events), such that clients just connecting onto it can begin streaming just from the beginning of that buffer, to end up with one complete "image" of the latest PTY state, minus any scrollback, without needing previous history. All that is kind of predicated on control-characters being embedded in the text and "following" the text around, such that taking a slice of the text (as the PTY's ring-buffer does every time a line is expunged) will preserve the corresponding slice of events. What would reading back the contents of a PTY device look like in a world with out-of-band TTY signalling? What would flow over a serial port? Would it even be a character-stream device, or are you imagining a TTY/PTY as operating in something more akin to a structured datagram event-stream mode, such that you'd use sendmsg(2) and recv(2) on it rather than write(2) and read(2)? I mean, it's not an impossible dream; but that really is a "start over with a whole separate ecosystem that no existing software works with until made compatible" kind of change. Effectively it'd be a separate thing from TTYs, that just happens to have similar functionality. But it wouldn't support any existing software, or any existing hardware, except by virtualization (i.e. running a PTY emulator process inside your modern OoB-signalling terminal emulator.) Kind of like what Windows has been going through to replace its own command-line. --- Personally, I'd prefer to keep in-band signalling (in the "in-band markup" sense above, not the "you have to recognize conventional escape-code sequences heuristically to even know they're not regular text" sense.) But I'd rather just make the in-band signalling structured — i.e. to make TTYs into a data-stream containing a variable-length self-synchronizing bit-encoding with clear prefix separation for control- and data- packets. Y'know, like UTF-8 is for text. ...or, well, speaking of Unicode: we could just use Unicode for this, reserving another block† of control characters to go with the 30-odd ones that sit at the beginning of the BMP. Then "is this is a control codepoint, and if so, what does it mean" could just be answered by consulting a Unicode table. (In such a setup, CSI command parameterization would be accomplished with zero-width joiners, variant selectors, and other things. Just picture control-characters as invisible emoji — specifically like the flag emoji that are formed by spelling out country-codes in a sort of "flags meta-alphabet"; or like that family emoji [https://emojipedia.org/family/ https://emojipedia.org/family/] with the combinatoric variants.) † Why not use the Private Use Area? Because this would be an explicitly inter-compatible signalling standard, not a proprietary usage. It's not text, but it is a standard signal within a text document. Just like emoji — or like the existing control codepoints in Unicode.
micouay 6y ago
I'd also really like to just be able to interact with a keyboard like other apps i.e. receive keyup events, reading multiple keys at once etc. Kitty has something like that but popular libraries don't support it. I've had many ideas for terminals games and apps but didn't continue because of these limitations.
aumerle 6y ago
This proposal is incomplete and has various bugs: https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#fixterms-bugs https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#fixte...
drran 6y ago
I have few mobile devices with limited keyboard: smartphones with keyboard, chromebook. They lack some keys presented on a standard PC keyboard. Will this new input library work with virtual keyboard, limited keyboard? How I will be able to input a missed key or control combination?
qwerty456127 6y ago
Indeed, terminals have to be fixed. Even DOS/Windows text mode (I don't mean the shell) always felt way better than a Linux terminal. Perhaps it finally is time to come up with an entirely new terminal technology re-engineered from [almost] scratch based on today achievements and needs. For a period of time near 2000 people felt like terminals were going to be abandoned in favor of GUIs so changing them didn't feel reasonable. But now it's clear that was wrong.
- enriquto 6y ago
  > Perhaps it finally is time to come up with an entirely new terminal technology re-engineered from [almost] scratch based on today achievements and needs. What do you mean, exactly, by that? Do you think that programs designed to work in current terminals (e.g., vim) should stop working with the new terminal technology? That seems a bit tough for progressive adoption. Otherwise, how do you think that these programs should be changed? Or wrapped in some intermediary "terminal emulator" so that they can run unchanged in the newer terminals?
  - qwerty456127 6y ago
    Why not? Also, the new terminal technology doesn't necessarily have to be fundamentally incompatible with the legacy technology. It probably can be made reasonably easy to compile classic apps for any terminal technology. Many of them are compatible (although not necessarily 100% compatible) with both Linux and DOS/Windows already.
bloak 6y ago
How does this interact with alternative and personalised keyboard layouts and with sticky keys for accessibility? I don't have a proper overview of how these things work, but I'm a bit worried that there may be multiple layers (reprogrammable keyboard, kernel, X server, terminal, editor) trying to solve similar problems in similar ways and they might end up interfering with each other.

135 points by smartmic 6y ago

Typing "echo <ctrl-v><esc>c<return>" to fix a garbled Vt100 like terminal remains embedded in my brain from long ago. Despite simpler things like "stty sane" existing. I don't know if maybe I was an admin on some box with a wonky stty, or why that's in my brain.

haecceity 6y ago
Is <ctrl-v><esc> same as \x1b? Why are they same?
- tyingq 6y ago
  Yes, 0x1b is an ascii <esc>. <ctrl-v> essentially means "insert the next key I press verbatim". So, like in Vim, <esc> would switch modes, unless you press <ctrl-v> first. Helpful if you're trying to insert a control character into a file, or echo a literal <ctrl-c> etc.
  - haecceity 6y ago
    Does the terminal emulator handle the ctrl-v or shell or somewhere in kernel?
    - deleted 6y ago
      [deleted]
    - jclulow 6y ago
      Whichever facility receives and processes the inbound keystrokes. In simple software that uses the terminal in canonical mode, the line discipline (usually in the kernel) handles the batching up of bytes into lines before passing them onto the software, and thus provides the line editing. In more complex software that puts the terminal into raw mode, it's then handled in that software; e.g., by libedit or readline or some bespoke terminal handling.
VMG 6y ago
I just type `reset` (maybe it's a zsh thing)
- tyingq 6y ago
  I don't remember, though I worked on a lot of oddball stuff. 3B2, Pyramid OSX, DGUX, etc.
drran 6y ago
Why not just `clear` or `reset` terminal?
- tyingq 6y ago
  Wish I could remember why not :). I know now, but the muscle memory sticks.

dan-robertson 6y ago

Personally I feel like the fix for terminals is not to use them. Emacs for example has a lot of effort put into supporting various different terminals and efficiently displaying text. Some xterm-specific support is for many colours, mouse support, and the control codes to ask xterm to send more precise key escape sequences so TAB and C-i aren’t confused for example. It also has a gui which doesn’t need to pile on layers of hacks and works great so long as you don’t need to go through a terminal (eg running over ssh.) And yet it is still straddled with backwards compatibility from those days (some users expect TAB and C-i to do the same thing.) To me it feels silly to put a lot of effort into supporting things better in terminal emulators because they are not as flexible as actual user interfaces and I think the main reasons we still have them are historical. Aside: I’d also like to see a command line shell which runs outside the terminal emulator rather than inside it.

nixpulvis 6y ago
All the issues are just matters of backwards compatibility at this point. As far as I'm concerned, we'll always need a text based REPL oriented interface.
coliveira 6y ago
You can also learn to use the terminal. This can clear many of the problems that you would otherwise have by thinking that the terminal is just another windows/macos application.
- dan-robertson 6y ago
  I don’t know how to respond to this as you seem to just think I’m an idiot who doesn’t know how to use computers. The problem with using a terminal is that control of it is distributed between a few things the user can control and the escape sequences (or just output) produced by the shell and any processes that run in it. These may end up conflicting with each other leaving your terminal in a bad state or you may just get broken output (ever tried piping pv something | ... | less?). One way to regain some control is with something like tmux but this can become unwieldy (and heaven forfend it sees a multibyte Unicode character—terminal emulators don’t really have a way to communicate with applications about how wide a character is going to be when drawn) I think a few things get conflated because there are few text-centric or command-line user interfaces. I put it to you that it is possible to have good composable text-centric user interfaces that don’t rely on pretending to be a VT100 or an ancient single-byte-stream-with-control-sequences protocol.

deleted 6y ago

[deleted]

vemv 6y ago

While I don't enjoy being negative, this doesn't sound like a solution that would work - it essentially needs 'boiling the ocean' i.e. convincing everyone else. (That's literally the plan described in the article) The first paragraphs of https://clojure.org/community/etiquette https://clojure.org/community/etiquette nail it: the software community is about making. If you want something done, make it. How would a "maker-driven" solution look like in this domain? For example: - make a terminal emulator that accepts the devised keybinding system - make at least one popular program (e.g. Emacs) play fine with said terminal - promote that combination, showing the world how the technology can in fact work. Word of mouth would do the rest.

aurelian15 6y ago
You are certainly not wrong. In this specific case however, I'd like to point out that the author, leonerd, has been busily working on "making stuff" to this end for years now. They are the lead author of libvterm, a popular modular terminal emulator library that is for example used in neovim and emacs-libvterm. They have also been working on libtermkey, a library that accepts input from the divised keybinding system, now part of libtickit mentioned in the post.
Scarbutt 6y ago
like this? https://iterm2.com/documentation-csiu.html https://iterm2.com/documentation-csiu.html
- mixmastamyk 6y ago
  Any other terminals support it?
- enriquto 6y ago
  seems cool but it is macOS-only
- hultner 6y ago
  Cool, so heat vemv requested already exists with iTerm and neovim.

gumby 6y ago

Excellent satire!

ashton314 6y ago

The conflation of various control characters, i.e. `Ctrl-i` and `Ctrl-I`, was one of the primary reasons that convinced me to try using Emacs outside of the terminal. I'm glad I switched. Now I can make much more ergonomic keybindings.

aidenn0 6y ago

I agree that using the 8-bit CSI to eliminate the escape ambiguity would be great. The rest I'm a bit "meh" on. In particular I use C-S as the modifier for my terminal shortcuts, so if the terminal could detect it I'd be looking for yet another set of bindings that no terminal programs will ever use.

alpaca128 6y ago
The only decent solution in my view would be a new, separate kind of terminal spec, maybe even completely focused at terminal emulators. It could make sense to handle input better(maybe even with keyup/keydown events) and maybe display images in a non-hacky way(it can already be done via w3m...kind of). Changing the existing standards just won't work as it would break a ton of programs, although if I'm being honest - while I like the idea of such a terminal rework - I don't know if it can be done nowadays without it opening the flood gates by developers who just can't restrain themselves from adding so many features it might as well be a new browser engine. And either way I don't think it's worth the effort as those input limitations only affect a few specific situations. I use hundreds of custom keybindings in Vim and so far the only obstacle I encountered was the `Tab` & `Ctrl-i` overlap. If I need to hold down more than one modifier I did something wrong anyway.
- aumerle 6y ago
  https://sw.kovidgoyal.net/kitty/keyboard-protocol.html https://sw.kovidgoyal.net/kitty/keyboard-protocol.html https://sw.kovidgoyal.net/kitty/graphics-protocol.html https://sw.kovidgoyal.net/kitty/graphics-protocol.html
  - alpaca128 6y ago
    Looks great, the only gripe I have with Kitty is how slow it is, especially on startup. I guess mostly because the combination of Python and tons of features has a negative effect in this area. In fact that was the only reason I switched away from it despite its great font ligature support; I use terminals a lot and so the constant delay when opening a new window was a bit much. However I like those modernised protocols and it would be neat to have widespread support for it.

mixmastamyk 6y ago

I didn't fully understand the spec, it got hard to read towards the end. Is this is supported by curses/terminfo?

Animats 6y ago

You can work directly at the keycode level, and watch the key up/down events. Many programs do, especially games.

duskwuff 6y ago
That doesn't work in a terminal. Terminals can operate over many different channels which don't pass through raw keyboard events (like SSH), or which don't have them at all (like serial links).

alanbernstein 6y ago

Can anyone point me to an article that explains why we are still stuck with these standards from the 1970s? I understand backward compatibility can be important, but I don't quite understand why terminal standards are the ONE thing in the computing world that just can not move into the future.

opk 6y ago
Just be glad that it didn't go the other way with terminals being full HTML 5 and having to watch advert videos between command invocations.
- m1gu3l 6y ago
  i think a few years ago someone tried to get me to try some terminal app that was Electron based. not AS bad but still... barf.
deleted 6y ago
[deleted]
enriquto 6y ago
> just can not move into the future. It can. How would you like them to move into the future? It's not as if there's been no recent evolution in terminal emulators. Notice that evolving into the future and using old ideas are not incompatible. Modern cryptography still uses Euclid's algorithm from more than two millennia ago.
- AnIdiotOnTheNet 6y ago
  > How would you like them to move into the future? For starters: stop using in-band signaling.
  - derefr 6y ago
    That's a big "for starters." In-band signaling — or rather, in-band markup — is a big part of what makes a "terminal" (i.e. a TTY/PTY device) semantically a "terminal": a hybrid character-grid / event-log that works both as a sink for streamed-in text, and as a "plotter" for making line-printer art. A device that both streams out as, effectively, an input-event log (where this log can be captured for replay, as with script(1) or most logging systems); but which also maintains a notion of being a ring-buffer "containing" a rectangularly-bounded volume of text (and control-events), such that clients just connecting onto it can begin streaming just from the beginning of that buffer, to end up with one complete "image" of the latest PTY state, minus any scrollback, without needing previous history. All that is kind of predicated on control-characters being embedded in the text and "following" the text around, such that taking a slice of the text (as the PTY's ring-buffer does every time a line is expunged) will preserve the corresponding slice of events. What would reading back the contents of a PTY device look like in a world with out-of-band TTY signalling? What would flow over a serial port? Would it even be a character-stream device, or are you imagining a TTY/PTY as operating in something more akin to a structured datagram event-stream mode, such that you'd use sendmsg(2) and recv(2) on it rather than write(2) and read(2)? I mean, it's not an impossible dream; but that really is a "start over with a whole separate ecosystem that no existing software works with until made compatible" kind of change. Effectively it'd be a separate thing from TTYs, that just happens to have similar functionality. But it wouldn't support any existing software, or any existing hardware, except by virtualization (i.e. running a PTY emulator process inside your modern OoB-signalling terminal emulator.) Kind of like what Windows has been going through to replace its own command-line. --- Personally, I'd prefer to keep in-band signalling (in the "in-band markup" sense above, not the "you have to recognize conventional escape-code sequences heuristically to even know they're not regular text" sense.) But I'd rather just make the in-band signalling structured — i.e. to make TTYs into a data-stream containing a variable-length self-synchronizing bit-encoding with clear prefix separation for control- and data- packets. Y'know, like UTF-8 is for text. ...or, well, speaking of Unicode: we could just use Unicode for this, reserving another block† of control characters to go with the 30-odd ones that sit at the beginning of the BMP. Then "is this is a control codepoint, and if so, what does it mean" could just be answered by consulting a Unicode table. (In such a setup, CSI command parameterization would be accomplished with zero-width joiners, variant selectors, and other things. Just picture control-characters as invisible emoji — specifically like the flag emoji that are formed by spelling out country-codes in a sort of "flags meta-alphabet"; or like that family emoji [https://emojipedia.org/family/ https://emojipedia.org/family/] with the combinatoric variants.) † Why not use the Private Use Area? Because this would be an explicitly inter-compatible signalling standard, not a proprietary usage. It's not text, but it is a standard signal within a text document. Just like emoji — or like the existing control codepoints in Unicode.

micouay 6y ago

I'd also really like to just be able to interact with a keyboard like other apps i.e. receive keyup events, reading multiple keys at once etc. Kitty has something like that but popular libraries don't support it. I've had many ideas for terminals games and apps but didn't continue because of these limitations.

aumerle 6y ago

This proposal is incomplete and has various bugs: https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#fixterms-bugs https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#fixte...

drran 6y ago

I have few mobile devices with limited keyboard: smartphones with keyboard, chromebook. They lack some keys presented on a standard PC keyboard. Will this new input library work with virtual keyboard, limited keyboard? How I will be able to input a missed key or control combination?

qwerty456127 6y ago

Indeed, terminals have to be fixed. Even DOS/Windows text mode (I don't mean the shell) always felt way better than a Linux terminal. Perhaps it finally is time to come up with an entirely new terminal technology re-engineered from [almost] scratch based on today achievements and needs. For a period of time near 2000 people felt like terminals were going to be abandoned in favor of GUIs so changing them didn't feel reasonable. But now it's clear that was wrong.

enriquto 6y ago
> Perhaps it finally is time to come up with an entirely new terminal technology re-engineered from [almost] scratch based on today achievements and needs. What do you mean, exactly, by that? Do you think that programs designed to work in current terminals (e.g., vim) should stop working with the new terminal technology? That seems a bit tough for progressive adoption. Otherwise, how do you think that these programs should be changed? Or wrapped in some intermediary "terminal emulator" so that they can run unchanged in the newer terminals?
- qwerty456127 6y ago
  Why not? Also, the new terminal technology doesn't necessarily have to be fundamentally incompatible with the legacy technology. It probably can be made reasonably easy to compile classic apps for any terminal technology. Many of them are compatible (although not necessarily 100% compatible) with both Linux and DOS/Windows already.

bloak 6y ago

How does this interact with alternative and personalised keyboard layouts and with sticky keys for accessibility? I don't have a proper overview of how these things work, but I'm a bit worried that there may be multiple layers (reprogrammable keyboard, kernel, X server, terminal, editor) trying to solve similar problems in similar ways and they might end up interfering with each other.