You don't need a terminal emulator · Andrey Listopadov(andreyor.st)
andreyor.st
You don't need a terminal emulator · Andrey Listopadov
https://andreyor.st/posts/2023-10-27-you-dont-need-a-terminal-emulator/
9 comments
There is a significant difference between async-shell-command and terminal emulators in that the latter allow programs to manipulate emulator state via escape codes, positioning the cursor, clearing screen, resizing the draw area etc. I think terminal emulators are inferior to the Emacs experience. They often exhibit issues when you try to select and copy multiline text in e.g. irssi or vim, where you suddenly need the underlying program to be X-aware for that to work properly. If something uses ncurses, it’s pretty much guaranteed to be broken in one way or another and it doesn’t have any of the programmatic benefits traditionally associated with command-line programs (piping). Terminal emulators simply emulate an outdated UI paradigm. Emacs UI although not perfect is in a completely different league.
> There is a significant difference between async-shell-command and terminal emulators in that the latter allow programs to manipulate emulator state ...
Hence why I said async-shell-command isn't technically a terminal emulator. It does, however, provide the same functional capability to launch a program, direct user input to it, and receive output from the program -- what most people are using terminal emulators for.
The big difference, in the authors described workflow, is they are launching these commands on an ad-hoc basis, not from a semi-permanent shell. That, I would argue, is the biggest practical difference between what most people are doing and what the author is describing.
Hence why I said async-shell-command isn't technically a terminal emulator. It does, however, provide the same functional capability to launch a program, direct user input to it, and receive output from the program -- what most people are using terminal emulators for.
The big difference, in the authors described workflow, is they are launching these commands on an ad-hoc basis, not from a semi-permanent shell. That, I would argue, is the biggest practical difference between what most people are doing and what the author is describing.
Author probaby should have used the name "ANSI escape terminal emulator"
That being said the whole point of the thing is not avoiding the interactive shell either, is the fact that ANSI escape terminal emulators are in fact "too advanced" and "too interactive" and you might not want that.
Those terminals execute pretty high level operations with the display in a complex in-band mechanism.
What I like about the emacs buffer approach is that it approximates the IBM 3270 handling of terminals; still online and interactive, still can refresh screen every keypress "if you really really want", but the expected approach to interactivity is receiving and submitting a-whole-screen/a-whole-form of information at once.
That being said the whole point of the thing is not avoiding the interactive shell either, is the fact that ANSI escape terminal emulators are in fact "too advanced" and "too interactive" and you might not want that.
Those terminals execute pretty high level operations with the display in a complex in-band mechanism.
What I like about the emacs buffer approach is that it approximates the IBM 3270 handling of terminals; still online and interactive, still can refresh screen every keypress "if you really really want", but the expected approach to interactivity is receiving and submitting a-whole-screen/a-whole-form of information at once.
I know many don't care about that but I care about one thing: input latency / lag. There have been many frontpage posts on HN about the subject of latency / input lag (including when it comes to terminals) over the years.
I've got a CPU doing billions and billions cycles per second and a badass monitor. I want my prompt to feel instantaneous.
And although I'm a big Emacs user and although Emacs is nowadays one of the fastest editor [1] out there (compared to IDEs like VS Code / IntelliJ or any Electron app), I don't feel like any of ansi-term / eshell / libvterm solution feels low latency / no input lag.
That's why although you can pry Emacs from my cold dead hands, I still use terminal emulators outside of Emacs.
I'd say 99.9% of the reason to use a terminal inside Emacs is anyway to cut/paste content from the buffer to Emacs: for that I use a shell script which pipes the output of my command into a new Emacs buffer.
[1] Time it takes to launch Emacs, execute Emacs Lisp code, and exit:
I've got a CPU doing billions and billions cycles per second and a badass monitor. I want my prompt to feel instantaneous.
And although I'm a big Emacs user and although Emacs is nowadays one of the fastest editor [1] out there (compared to IDEs like VS Code / IntelliJ or any Electron app), I don't feel like any of ansi-term / eshell / libvterm solution feels low latency / no input lag.
That's why although you can pry Emacs from my cold dead hands, I still use terminal emulators outside of Emacs.
I'd say 99.9% of the reason to use a terminal inside Emacs is anyway to cut/paste content from the buffer to Emacs: for that I use a shell script which pipes the output of my command into a new Emacs buffer.
[1] Time it takes to launch Emacs, execute Emacs Lisp code, and exit:
$ time emacs -Q -nw -eval '(kill-emacs)'
real 0m0.049s
It's one of the reasons I really like xterm; besides starting up reasonably fast, actually supporting ANSI escapes and not some random subset of them it had one of the lowest input-to-screen latency ranges of all emulators.
- and overall embedding random things like Sixel and tektronics graphic terminal emulation, and correctly handling Unicode and bidi, and supposedly having garbage stdout rendering speed - but I believe if you're dumping several million screenfulls of scrolling text you're holding your terminal wrong.
- and overall embedding random things like Sixel and tektronics graphic terminal emulation, and correctly handling Unicode and bidi, and supposedly having garbage stdout rendering speed - but I believe if you're dumping several million screenfulls of scrolling text you're holding your terminal wrong.
I really like the fact that using the CLI that way feels very 3270-ish web-1.0-ish, that things move when you decide so and that things remain static for as long as you want.
[deleted]
Well, to each his own, but I've been using bash and vim for 99% of my technical work and it suits me very well. It's going to be there on every box I can think of logging into, default config works fine in some cases (if they don't I memorized the 6 lines of vimrc I need), and in 10 years with this workflow I'm still unsure how to install a plugin so it's not like I need those anyway.
> …if you’re an Emacs user, that is.
It shouldn't be a surprise, given its relationship with Lisp based computers, and Emacs inspired IDEs in Lisp Machines, with integrated REPL.
Unless the shell exposes the whole OS stack like Fish or Powershell, a REPL is much more powerful.
It shouldn't be a surprise, given its relationship with Lisp based computers, and Emacs inspired IDEs in Lisp Machines, with integrated REPL.
Unless the shell exposes the whole OS stack like Fish or Powershell, a REPL is much more powerful.
Last time I checked all terminal emulators available in Emacs showed visible lag when rendering output. Not really suitable for serious work on the terminal.
> Last time I checked all terminal emulators (...) showed visible lag when rendering output. Not really suitable for serious work on the terminal.
Why do you think that a subjective assessment of some lag automatically disqualifies a terminal emulator from being "suitable for serious work"?
I mean, what's this "serious work" that you do that is sabotaged by a few milliseconds of lag?
Why do you think that a subjective assessment of some lag automatically disqualifies a terminal emulator from being "suitable for serious work"?
I mean, what's this "serious work" that you do that is sabotaged by a few milliseconds of lag?
Vim has a built in terminal emulator, but I have still yet to use it.
For me, the ultimate dev setup is really tmux plus vim (and other command line tools).
For me, the ultimate dev setup is really tmux plus vim (and other command line tools).
Um, yeah.
> You don't need a terminal! Look at all the stuff I do without one...
[...]
> Oh, but, yeah, I totally use eshell + EAT.
> Why do you need a terminal?
> You don't need a terminal! Look at all the stuff I do without one...
[...]
> Oh, but, yeah, I totally use eshell + EAT.
> Why do you need a terminal?
yffsits7(1)
The article would make more sense if the author said 'you may not need an interactive shell. Here's how to use a pseudo-terminal-emulation mode in Emacs to launch commands without using a shell.'