sixel-tmux

gic 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 BTW you should package your emacs config file with the emacs APE from https://cosmo.zip/pub/cosmos/bin/emacs to do a cuteemacs, to carry your config files and everything in a portable binary: https://github.com/csdvrx/CuteVim 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

it's the true spirit of hacking. > i have done the same. I made a couple of attempts to switch to nvim the last of which was abandon just over a month ago. TBH I never really tried neovim, maybe because I like the start screen of vim? The idea of doing something for orphans may be cheezy, but I really like the message! Also why did you attempt to switch to neovim? I don't feel any limitation in vim. I'd be curious to know why you tried. I felt them in tmux (lack of sixel support) or bash (incomplete history file), but instead of doing the sensible thing such as using zsh within kitty like everyone else, I spent some time to have tmux intercept and transcode sixel sequences into "ascii art" (https://github.com/csdvrx/sixel-tmux/) have bash save commands start and stop time in a sqlite database (https://github.com/csdvrx/bash-timestamping-sqlite) > I have a very hard time articulating what I like more about Vim other than simply it just suits me better (which isn't an interesting answer). I see what you mean. I didn't like zsh when I tried it last time I tried to move to Linux on the desktop. I liked hyprland - it sealed the whole linux-on-the-desktop deal. It "suits me better", but it's new so I think (or I hope?) it's not just by weird interest in retrocomputing that makes me prefer bash+vim to zsh+neovim :)

or most use. I think the tech has been adequate for some time (at least about 15 years), and I can freely recognize that both because I have no horse in the game, and I care more about actual use than having/creating a shiny new tech. Inventing a better wheel is the perfect way to avoid confronting such issues: you can argue your new wheel is better, and technically it will be true, even if in practice it's no different that the old wheel, in the sense it allows your vehicle to go forward for all the practical measures you care about. There may also be a loss-aversion effect: if what you invented that was great is no longer needed, it may be painful to recognize it. You may not want to go for what's technologically not as nice as your invention, but that can now do the job just as well as your invention did, thanks to Moore's law. Some people also just want to see their favored pet idea to win - unfortunately, they pet idea is only theoretical, or if it exists, it has a very small install base: since sixel is "adequate" or "sufficient", blocking/sabotaging sixel support is the logical action to prevent it from becoming established through network effects. Put all these people together, add a little handwaving about how old formats can't work, and you get the current situation. BTW here's a project I'll try to resurect: rending X applications ... in sixels: https://github.com/csdvrx/xorg-sixel So you could have graphical applications in your terminal! I've just up. I've only uploaded the picture as I'm still fighting with the code but what you see is Xeyes show inside wezterm thanks to the sixel output of Xorg. For terminals that don't support sixels (yet), sixel-tmux will convert them "in flight" into derasterized graphics: see https://github.com/csdvrx/sixel-tmux/ I'm sure this tech stack (X apps -> Xsixel -> sixel-tmux -> text) will make many people cringe, but in terms of functionality, it works (latency, bandwidth etc are sufficient for my uses) and if you have sixel support in your terminal, you get pixel perfect results. FWIW I use and love Hyprland, but I want to use portable graphics apps more than I care about the underlying tech being better.

(or if you use the scrollback buffer, to save or RAM), render a unicode representation instead (like Chafa), but if it does, pass through the original sixel sequence.