Hi there !
I’ve recently migrated from neovim to kakoune, and it’s been a blast learning all this new stuff and playing around with the editor.
My configuration is at a bare minimum for now, like just clippy->cat and custom :cq command. No plugins, no nothing.
Before getting into all this fun config stuff, I would like to set up my terminal multiplexer since kakoune doesn’t directly implement splits.
Although, I don’t want to use tmux as it ships with a lot of features I won’t even use once.
I’m currently looking at mtm which is really minimal with maybe 6-8 commands tops.
The only issue is its color support, which is only up to 256 colors.
Has any of you ever worked with implementing true colors for this type of program and if so, would you be so kind to link me with some useful resources ?
I tried to find the ncurses documentation for direct colors, but didn’t find anything interesting…
Also, I’ve taken a look at st terminal source code, since it supports true colors, but I’m guessing a terminal client and a multiplexer work differently, I don’t know if it’s worth exploring deeply.
I’m willing to put a lot of learning and efforts into this issue, I just need a hand as I’ve never worked with this kind of program.
Once I’ve managed to add true color support, I plan on writing a small plugin to use mtm as tmux from within kakoune.
I’ve created my own fork (sourcehut: ~nasmevka/mtm) since the current mtm owner has stated it won’t implement true colors as he wants it as bare as possible.
I imagine there’s two reasons mtm might only implement 256 colours:
it only wants to store two bytes (foreground and background) of colour data per cell, not eight or more
it’s using ncurses, and while ncurses’ true-colour mode goes to great lengths to support true-colour in the traditional curses model, that’s not the model applications expect, so it would make the multiplexer even more complicated
As an example, Kakoune only bothered to implement true-colour support once it stopped depending on ncurses.
One other option to consider if your multiplexer only supports 256-colours: it’s easy to patch Kakoune to use an approximation from that palette instead of requesting the exact 24-bit colour.
In my local build, I have https://github.com/arachsys/packages/blob/master/kakoune/palette.diff which should apply against both the most recent release and current master. I don’t use this much, but it’s really handy when I find myself accessing one of my machines from an older terminal.
To be honest, I don’t notice the slight colour-infidelity when I turn it on, although it’s just about visible if I open two terminals side-by-side. The original thread has a screenshot.
That’s what bothering me the most with the true color approach, I’m afraid it might not be as compatible as mtm is right now.
I might go with @ChrisW, as palette approximation might just be good enough for my use case, letting others send patches if they really want true color support.
I just don’t want kakoune to look like hot garbage as it does currently through mtm.
Yes. This is what, for example, tmux does if an app inside the multiplexer tries to use true-colour output and the terminal outside the multiplexer doesn’t support it.
Is that the default theme? Even without true-color support, Kakoune’s default theme (and any theme based on the standard 16 terminal colours) should be fine. If it’s not, that’s an additional problem.
Is that the default theme? Even without true-color support, Kakoune’s default theme (and any theme based on the standard 16 terminal colours) should be fine. If it’s not, that’s an additional problem.
Yes and this might well be quite easy. As a first step, you could just implement a simple translation from the 24-bit escape into a colour-palette escape at the program-facing side of the multiplexer without changing anything in the internal representation at all. This would have the side-effect that colour-readback would give the palette entry, but that’s probably what you want because programs that detect 24-bit vs 256-colour support would fail to read back a 24-bit colour and use the 256-colour mode directly.
If you’re translating RGB to the default xterm palette, it’s worth special-casing greys as my patch does. The 6x6x6 cube would give you relatively poor greyscale resolution compared to the special range at the end of the palette.
As a first step, you could just implement a simple translation from the 24-bit escape into a colour-palette escape at the program-facing side of the multiplexer without changing anything in the internal representation at all
@ChrisW, thanks a lot ! Will give it my best and keep people inform of my progression in this thread if that’s alright !
@Screwtapello thank you too for all the resources you gave me. Might give a look at true colors once I’m more comfortable with mtm code base.
It’s weird that the default theme doesn’t show the cursor. Perhaps the “everforest” theme sets up things that don’t get reset when you try to switch back to the default.
Rather than launching Kakoune with the custom theme then switching to the default, does it work better if you comment out the colorscheme command in your kakrc, or just run kak -n (which ignores all your config files)?
Perhaps the “everforest” theme sets up things that don’t get reset when you try to switch back to the default.
Yeah… I completely forgot that I have hooks running to change the cursor color when changing mode. They use rgb colors of course, so that explains the no cursor issue I think…
Launching kak -n from within mtm works flawlessly. Sorry for the false alarm…
When this issue was created, yes.
Now, though, mtm supports all 256 colors.
What is really missing to support kakoune, is either 24bit true color parsing or 256 colors palette approximation as @ChrisW mentioned.
I decided to go with the latter as it’s easier to implement, and I don’t know mtm source code nor ncurses color handling enough.
I might create another branch later with true color support.
