2 ms·

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

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.