Add support for true color

[pickfire]

I hope dvtm can implement truecolor support.

https://gist.github.com/XVilka/8346728

[XVilka]

Providing an update - so far, only dvtm doesn't have support for True Colors among terminal multiplexers:

• [x] tmux - starting from version 2.2 (support since 427b820...)
• [x] screen - has support in 'master' branch, need to be enabled (see 'truecolor' option)
• [x] pymux - tmux clone in pure Python (to enable truecolour run pymux with --truecolor option)

And now - most of the terminals supporting it as well, except a few only - Terminology, PuTTY, GTK2Term, sjterm and xfce terminal (on it's way in 4.14, because of GTK+3 migration, thus higher libvte version, thus true color support).

[pickfire]

@XVilka Wow, thanks a lot for the info.

[paride]

As far as I know, this is a known ncurses limitation and there no easy way around it, see:

http://invisible-island.net/ncurses/ncurses.faq.html#xterm_16MegaColors

Here is what urxvt does (http://lists.schmorp.de/pipermail/rxvt-unicode/2016q2/002261.html):

Support directly setting RGB fg/bg colors via ISO-8613-3 24-bit ANSI color escapes [...] To avoid memory overheads and keep the patch non-intrusive, it takes the approach to adapt the nearest color in an hidden 6x6x4 (88-color mode) or 7x7x5 (256-color mode) color cube to the new 24-bit RGB color.

I wonder if dvtm could do something similar.

[vvug]

Any news on this? It's a pity that your editor Vis outputs truecolors, but dvtm does not support them...

[vvug]

Any possibility to fix this as you did in https://github.com/martanne/vis/issues/356?

[whitelynx]

As far as I know, this is a known ncurses limitation and there no easy way around it

As of version 6.1, ncurses has direct-color support; see https://www.gnu.org/software/ncurses/

Would simply upgrading ncurses be sufficient to fix this?

[vvug]

Sure enough, just compiling against libncurses 6.1 doesn't bring truecolor support. I really hope @martanne chimes in.

[rpmohn]

@martanne - It looks as if it might be somewhat straightforward to the truecolor-type changes you made in vis/ui-terminal-curses.c to dvtm/vt.c. Do you have thoughts on this? It would be very nice! If you give me a nudge I might even do it myself, but I'd like to hear your thoughts first. Thanks! -Ross

[ghost]

This is feature to render tmux obsolete!

[victorz]

This light-weight multiplexer is a real tmux-killer, if it weren't for the lack of true-color. Really cool and useful CLI color utilities like pastel do not work well in dvtm due to the lack of true-color support. I really endorse this effort to bring it to dvtm. :slightly_smiling_face:

[kuator]

Colors :(

[harryhaaren]

Hey Folks, bumped into this too today, done a quick check on implementing 24 bit true-colour in DVTM, got a few segfaults (color_index[] overruns when COLORS > 256, the color_hash() function returns out of bounds, results in segfault... got disheartend).

I'm currently toying with https://zellij.dev/documentation/overview.html instead, which has TrueColor support, and with some keybinding customization can be functionally quite similar to dvtm I think. It also provides dtach like functionality.

I've been a long time dvtm fanboy, but I want/need 24 bit colors for the Helix editor themes... DWM, DVTM and ST folks, thanks for your work - its great, and I've happily used it for years.

[rpmohn]

Don't get too excited yet, but I've been working on a rewrite of dvtm called a4, using libtickit and libvterm, that supports 24 bit colors along with some other features, such as a text configuration file rather than requiring recompilations and support for full colorscheme colorrules, not just fg/bg. I'm on a short vacation from its development but should get back to it very soon. It needs some cleanup but does basically work well! More details are at https://a4term.com and suggestions and encouragement are very welcome. -Ross

[harryhaaren]

Hey Ross, thanks for the info - checked out the site, nice clean description of the goals. I didn't find a link to the code - so I guess its not available yet? Do ping here when it is, will give it a compile & test! Regards, -Harry

[rpmohn]

Code not available yet, will definitely ping here when it is.

[rpmohn]

Announcing the first public code release of a4, a dynamic terminal window manager. There are still improvements to be made but the tool is essentially working now. A4 is a partial rewrite of dvtm, which in turn is a text-based implementation of dwm. A4 replaces the ncurses back end with libtickit for text drawing and keyboard and mouse input processing. In addition, terminal processing is performed using the libvterm library.

This first release of a4 provides several new features, including support for more complete, 24bit, dynamic colorizing, and configuration in an a4.ini file. See https://a4term.com/ for documentation, including installation instructions, a copy of the manual page, and default keyboard maps.

[kuator]

Announcing the first public code release of a4, a dynamic terminal window manager. There are still improvements to be made but the tool is essentially working now. A4 is a partial rewrite of dvtm, which in turn is a text-based implementation of dwm. A4 replaces the ncurses back end with libtickit for text drawing and keyboard and mouse input processing. In addition, terminal processing is performed using the libvterm library.

This first release of a4 provides several new features, including support for more complete, 24bit, dynamic colorizing, and configuration in an a4.ini file. See https://a4term.com/ for documentation, including installation instructions, a copy of the manual page, and default keyboard maps.

This is awesome! IMO, I would prefer having one MOD keybinding prefix by default, but that's just my opinion

[rpmohn]

Just update those mappings in your own ~/.config/a4/a4.ini file and you're good to go. For me, separating Ctrl-g for "Go" commands and and Ctrl-a for "Arrangement" commands makes the actual keys used for keybindings less arbitrary. Take a look at /usr/local/share/a4/a4_dvtm.ini for an implementation of those old defaults, though it's a limited overall use of a4. Here's an example ~/.config/a4/a4.ini customization file to get you started; you only need to specify the things you want to change.

include = /usr/local/share/a4/a4.ini

[KeyboardActions]
C-a f =
C-g f = layout fullscreen
C-a g =
C-g g = layout grid
C-a h =
C-g f = layout zoom_left
...

[kuator]

Just update those mappings in your own ~/.config/a4/a4.ini file and you're good to go. For me, separating Ctrl-g for "Go" commands and and Ctrl-a for "Arrangement" commands makes the actual keys used for keybindings less arbitrary. Take a look at /usr/local/share/a4/a4_dvtm.ini for an implementation of those old defaults, though it's a limited overall use of a4. Here's an example ~/.config/a4/a4.ini customization file to get you started; you only need to specify the things you want to change.

include = /usr/local/share/a4/a4.ini

[KeyboardActions]
C-a f =
C-g f = layout fullscreen
C-a g =
C-g g = layout grid
C-a h =
C-g f = layout zoom_left
...

Thank you, I followed your suggestion. Another question is do you have any plans for copy-mode? I think it's one of the killer features of dvtm.

[rpmohn]

Yes, copy-mode is very high on the list of next features! It went through several different implementations in dvtm, and I'm not sure yet what to use in a4.

[kuator]

Yes, copy-mode is very high on the list of next features! It went through several different implementations in dvtm, and I'm not sure yet what to use in a4.

Awesome, can't wait!