This reminds me of how this 3270 terminal worked. You sent the terminal a bunch of text to display, and a list of editable regions on the screen. Then only when you edited some things and hit enter were the editable regions sent back. It led to some interesting UIs compared to a typical terminal.
And it was bad at other use cases, having used both (3270 and vt) you can do 3270 workloads on a vt(granted less efficiently) but vt style asynchronous updates were very hard on a 3270.
If I had to pick one I would pick the vt.
And footnote, while technically I have worked with 3270's, my experience was using rexx on vse/cms. That is to say my use of the 3270 was hampered by about 5 levels of application framework, perhaps if I used them more directly I would be more charitable.
Right, the great advantage of the 3270-style block-mode model was that your 0.5-MIPS mainframe didn't have to handle an interrupt for every keystroke, so it could serve, I don't know, 100 terminals. Same as HTML <form> and half-duplex line-mode terminals with local echo.
An in-between version is how csh and vi would set eol2 (I think?) to ^[ so that most user interaction could be done in "cooked mode" until you hit ESC or ^D. This still required an interrupt for every keystroke on your 1-MIPS PDP-11, but at least it didn't require a context switch to the shell or editor process in order to echo normal printing characters. The kernel would handle echoing characters back to the terminal, deleting characters with ^? or ^H, and deleting words with ^W.
(As I understand it. I used csh and vi, but never on a PDP-11.)
Neovim and vim both support different APIs for something similar that seems like it isn't quite as useful as Emacs version for this use case. Vim has textprops and Neovim has extmarks, and while you could implement something that made these read-only, it doesn't seem like there is just an option to make it so. Both features seem mostly designed to support virtual text / compiler diagnostics, rather than enabling Magit-style interfaces.
I would love to see more buffer-centric interfaces in vim (fugitive, oil) and less popup-centric interfaces (lazy, mason).
This reminds me of how this 3270 terminal worked. You sent the terminal a bunch of text to display, and a list of editable regions on the screen. Then only when you edited some things and hit enter were the editable regions sent back. It led to some interesting UIs compared to a typical terminal.
And it was bad at other use cases, having used both (3270 and vt) you can do 3270 workloads on a vt(granted less efficiently) but vt style asynchronous updates were very hard on a 3270.
If I had to pick one I would pick the vt.
And footnote, while technically I have worked with 3270's, my experience was using rexx on vse/cms. That is to say my use of the 3270 was hampered by about 5 levels of application framework, perhaps if I used them more directly I would be more charitable.
Right, the great advantage of the 3270-style block-mode model was that your 0.5-MIPS mainframe didn't have to handle an interrupt for every keystroke, so it could serve, I don't know, 100 terminals. Same as HTML <form> and half-duplex line-mode terminals with local echo.
An in-between version is how csh and vi would set eol2 (I think?) to ^[ so that most user interaction could be done in "cooked mode" until you hit ESC or ^D. This still required an interrupt for every keystroke on your 1-MIPS PDP-11, but at least it didn't require a context switch to the shell or editor process in order to echo normal printing characters. The kernel would handle echoing characters back to the terminal, deleting characters with ^? or ^H, and deleting words with ^W.
(As I understand it. I used csh and vi, but never on a PDP-11.)
And it had on device buffering, so you could punch in a bunch of commands and be sure they would be received.
Neovim and vim both support different APIs for something similar that seems like it isn't quite as useful as Emacs version for this use case. Vim has textprops and Neovim has extmarks, and while you could implement something that made these read-only, it doesn't seem like there is just an option to make it so. Both features seem mostly designed to support virtual text / compiler diagnostics, rather than enabling Magit-style interfaces.
I would love to see more buffer-centric interfaces in vim (fugitive, oil) and less popup-centric interfaces (lazy, mason).