mlterm VS st

In XTerm, this (rightly) makes no difference. In Foot and Contour however, you still end up a line resp. a screen below where you started, if now with the correct horizontal position.

So it seems to me like what you want should work by default, except it doesn’t.

It should be possible to instead just treat the whole thing as a graphical overlay (by computing or directly asking for the character cell size, as Kirill Panov rightly admonishes me is possible with XTWINOPS) without touching the cursor; that’s what the “sixel scrolling” setting (DECSDM) is supposed to do. Then you can just manually move the cursor forward however many positions after you’re done drawing.

Except apparently the DEC manual (the VT330/340 one above) and DEC hardware contradict each other as to which setting of DECSDM (set or reset) corresponds to which scrolling state (enabled or disabled), and XTerm has implemented it according to the manual not the VT3xx[1,2,3]—then most other emulators followed suit[4]—then XTerm switched to following the hardware[5,6] (unless you and that’s what I’m seeing on my machine right now. So now you need to check if you’re on XTerm ≥ 369 or not[7]. If I’m reading the Notcurses code right, other terminals have followed suit[8].

Again, ouch.

P.S. It seems DEC had an internal doc for how their terminals should operate (DEC STD 070) [9]. It does not document DECSDM at all.

[1] https://github.com/wez/wezterm/issues/217#issuecomment-86449...

[2] https://github.com/hackerb9/lsix/issues/41

[3] https://github.com/dankamongmen/notcurses/issues/1782

[4] https://github.com/arakiken/mlterm/pull/23

[5] https://invisible-island.net/xterm/xterm.log.html#xterm_369

[6] https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-T...

[7] https://github.com/dankamongmen/notcurses/commit/0918fa251e2... (the correct version cutoff is 369 not 359, the patch contains a now-fixed bug)

[8] https://github.com/dankamongmen/notcurses/blob/master/src/li... (look for mentions of invertsixel)

[9] http://www.bitsavers.org/pdf/dec/standards/EL-SM070-00_DEC_S...

> you need to "edit your makefile". That isn't going to work for distributions

Is it not? [st] requires exactly that. And distros seem to have no issues shipping it.

[st] https://st.suckless.org/

I am fundamentally and ideologically opposed to using a terminal emulator implemented in electron.

If you feel similarly, then you might enjoy https://st.suckless.org/

You can use different forks of the ST. I, for example, use this one, already with the necessary patches https://github.com/mrdotx/st

kiss with kiss-xorg, nsxiv, st, dmenu with script, tewi, fet.sh

My journey of using terminal emulators began together with my introduction to Linux about 7 years ago. GNOME terminal was my first as it came pre-installed on Ubuntu, my first Linux distribution. Since then, I've had the opportunity to explore and utilize a range of terminal emulators, including Alacritty, Kitty, st, Konsole, xterm, and most recently iTerm2. It's been interesting to experiment with these different emulators, each offering its unique features (or similar however with each with personal touch), user interfaces, and performance benchmarks. Just the other day, a new terminal emulator caught my attention: Warp Terminal. My curiosity won, and Warp was downloaded, this short blog are my thoughts about Warp terminal. At the moment there is only support for macOS, however linux and windows builds are on the way.

Terminal : st

For those looking for a minimal VT100 terminal emulator without the legacy baggage of Xterm, I highly recommend checking out Suckless Software’s st: https://st.suckless.org/

That last reference builds off of the work of the other two. It also breaks down how NOT modern Xterm is, but, if I've read it correctly, it confirms that its input latency is low compared to all other tested terminal emulators, including Alacritty and ST, which humorously and justifiably thrashes Xterm on its homepage for being a bloated program. Its not a good choice for everyone: it has poor right-to-left text and Unicode support, making working with Chinese, Arabic, and other alphabets not great, I've read.

ST is a favorite of some fervent minimalists. I do not think you would like it.