I suspect the author would have had a better time had they known to do "export COLORTERM=truecolor". This is mentioned in a footnote in the linked Emacs document about detecting truecolor support, and it appears in their Konsole screenshot, but I suspect it got lost inside their layers of terminal multiplexers (as, I find, it often does). It lets you skip past all this hard stuff straight to the part where the app understands that you want true color. A terminfo database isn't even required.
Agreed - COLORTERM has its own problem. I prefer your approach, it looks very sound!
A fork of terminfo may be needed if the description of modern terminal capabilities can't be added -- or if old and deprecated attributes repurposed for that job (like in your padding example): if you're automating the correction/creation of terminfos in ~/, IMHO, it may be better to piggyback on tic as much as possible.
Anyway, to backport modern terminal descriptions to legacy programs, creating correct binary terminfos in ~/.terminfo seems the best practice. You can also invent new TERM. When I wanted to have italics etc about everywhere, personally that's just what I did for sixel-tmux: https://github.com/csdvrx/sixel-tmux/?tab=readme-ov-file#ste... : just declare a new $TERM you know to be right, and use that in the apps that let you use a little logic in their configuration file
I do that in my .vimrc:
" If Vim doesn't know the escape codes to switch to italic
let &t_ZH="\e[3m"
let &t_ZR="\e[23m"
" Italics pseudo-auto toggle: force italics if we recognize it's supported from TERM
if match($TERM, "xterm-256color-italic")==0
highlight Comment cterm=italic
endif
Another idea: have you considered that the "program that would be run by .bashrc" to generate the "unambiguous 24-bit color capabilities" could set environment variables to communicate them? Like, if you can't stuff them in terminfo, stuff them in environment variables! Env var work well on Windows, and the configuration files of terminal programs could just use these when available to override.
It's be like adding friends to your proposed TERMVERSION: TERMSETF24 etc where you've have a finer control than COLORTERM
I have tried to love TRAMP, but I can't figure out how to get eglot to work properly. I use it for C++ in a large codebase, so eglot is mandatory.
The other thing is that I like to close my laptop, reopen it the next day, and have access to the same remote buffers. (Maybe this is possible with TRAMP.)
Ultimately I just use emacs in tmux over ssh, with CLICOLOR defined appropriately, and this gets me 95% of what I want.
I wish I could get rid of those last <50ms of keypress latency. And variable-sized fonts for eglot inlay type annotations. They are quite distracting when they're the same size as the code.
TRAMP remote buffers aren’t a huge issue on disconnection because the buffer contents are stored locally: TRAMP’s magic mostly occurs on open and save. Unfortunately, your modew like eglot have to be TRAMP-aware and execute over a ssh connection somehow. Many LSP servers use stdio communication, so it should be possible to put together a mode hook that detects if the buffer file name is a TRAMP file name and then does something like `ssh remotehost -- cd /project/root ‘&&’ clangd --stdio`
Eglot does that automatically though. It detects when you're in TRAMP and launches the language server in a remote. Of course, it assumes that the language server exists at the remote, but that should be the case.
COLORTERM is also a very weird thing. Most of the time I don't need it to be defined, but when using a screen session it suddenly looks very crappy when COLORTERM is set to truecolor. Removing the env var makes it look all normal again.
Tmux supports 24-bit color. I bit the bullet and switched a few years ago, and my muscle memory remains exactly the same. I'm incredibly happy with the power, flexibility, configurability, and reliability of Tmux.
If unsetting COLORTERM fixes the display problem then it is a program issuing 24bit colors but the terminal (in your case screen) not understanding the escape sequences.
