3 ms·

>You should always paste into an editor first and that editor should not be running "inside" a terminal -- or rather I don't understand why those that like in

>You should always paste into an editor first and that editor should not be running "inside" a terminal -- or rather I don't understand why those that like interacting with their editor via a terminal interface don't create a new protocol that doesn't have the warts and vulnerabilities the current ancient protocol has.

arp242 3y ago
Compatibility, basically. e.g. Vim creating their own protocol is rather pointless if no terminal implements it, and some terminal creating their own protocol is also rather pointless without application support. Plus there's tons of software out there and it'll take a long time for it all to be rewritten, if that ever happens. e.g. X11 will still be around for a long time as well. So you will need to remain compatible with the current protocol even if you invent something new and better, and in that sense it doesn't really fix anything., at least not right now. It might fix stuff 15 years down the line, maybe, but in-between now and 15 years everything will be more complex by having two protocols. And all things considered, it's not that bad, IMHO. There's the KiTTY Keyboard protocol to solve some obvious UX issues with keyboard handling, which is a clear improvement and motivation, whereas some exploit vectors that don't really see live exploits isn't really.
- hollerith 3y ago
  There are dozens of toolkits for authoring GUIs, which are much more complicated than the protocol we are talking about and consequently much more work, so, no I don't see why the Vim project cannot take on the work of defining a new protocol and maintaining a client that speaks the protocol. The hairiest Emacs Lisp code I know about is the code for responding to mouse actions, e.g., clicking and dragging, and most Vim users don't even want to use a pointing device to interact with Vim IIUC. (In contrast, 80% of Emacs users who responded to a survey do not interact with Emacs through a terminal interface.) For example, the old scripting language Tcl has its own GUI toolkit named Tk that has a pretty good reputation. >And all things considered, it's not that bad It seems bad enough to me to be worth re-architecting.
  - arp242 3y ago
    But GUI toolkits work very different; ProgA can link against GTK, ProgB against Qt, ProgC against Tk, and that all just peacefully coexist without problems (short of perhaps some UI inconsistencies). None of these toolkits have to even be aware that the others exist for it all to work; there is no shared protocol (other than the system itself: X11, whatever Windows has, etc. – and look at how long s/X11/Wayland/ is taking, and there is considerable disagreement whether Wayland is even an improvement in the first place). But in a terminal all code runs in that terminal, and terminal programs don't "link against" a terminal in the same way that you do with a GUI toolkit. You need to implement a shared protocol on both ends.

arp242 3y ago

Compatibility, basically. e.g. Vim creating their own protocol is rather pointless if no terminal implements it, and some terminal creating their own protocol is also rather pointless without application support. Plus there's tons of software out there and it'll take a long time for it all to be rewritten, if that ever happens. e.g. X11 will still be around for a long time as well. So you will need to remain compatible with the current protocol even if you invent something new and better, and in that sense it doesn't really fix anything., at least not right now. It might fix stuff 15 years down the line, maybe, but in-between now and 15 years everything will be more complex by having two protocols. And all things considered, it's not that bad, IMHO. There's the KiTTY Keyboard protocol to solve some obvious UX issues with keyboard handling, which is a clear improvement and motivation, whereas some exploit vectors that don't really see live exploits isn't really.

hollerith 3y ago
There are dozens of toolkits for authoring GUIs, which are much more complicated than the protocol we are talking about and consequently much more work, so, no I don't see why the Vim project cannot take on the work of defining a new protocol and maintaining a client that speaks the protocol. The hairiest Emacs Lisp code I know about is the code for responding to mouse actions, e.g., clicking and dragging, and most Vim users don't even want to use a pointing device to interact with Vim IIUC. (In contrast, 80% of Emacs users who responded to a survey do not interact with Emacs through a terminal interface.) For example, the old scripting language Tcl has its own GUI toolkit named Tk that has a pretty good reputation. >And all things considered, it's not that bad It seems bad enough to me to be worth re-architecting.
- arp242 3y ago
  But GUI toolkits work very different; ProgA can link against GTK, ProgB against Qt, ProgC against Tk, and that all just peacefully coexist without problems (short of perhaps some UI inconsistencies). None of these toolkits have to even be aware that the others exist for it all to work; there is no shared protocol (other than the system itself: X11, whatever Windows has, etc. – and look at how long s/X11/Wayland/ is taking, and there is considerable disagreement whether Wayland is even an improvement in the first place). But in a terminal all code runs in that terminal, and terminal programs don't "link against" a terminal in the same way that you do with a GUI toolkit. You need to implement a shared protocol on both ends.