search

cosmos72 / twin

Text mode window environment. A "retro" program for embedded or remote systems, that doubles as X11 terminal and text-mode equivalent of VNC server
Other
648 stars 38 forks source link

support xterm-256color emulation? #30

Open farmboy-isa-dev opened 6 years ago

farmboy-isa-dev commented 6 years ago

I rarely work in an environment w/o 256 color support and have gotten used to vim w/ more than 16 colors, so I'd be interested in adding support to emulate xterm-256color in twin. Any thoughts about how difficult this would be? Suggestions about where to focus in the twin code base?

FYI, a secondary reason for emulating xterm-256color is I like 'set cursorline' in vim - but with TERM=linux, instead of underlining it turns off syntax highlighting on the current line. The vim documentation mentions that this is due to limitation in some terminal types. I confirmed this appears to be due to TERM=linux (not a bug in twin) by reproducing the behavior in a linux virtual console.

cosmos72 commented 6 years ago

I thought about adding 256-color support several times in the past, and even adding 64k or 16M color support.

While certainly useful and not overly difficult, it requires extending the 'hwattr' type, that contains Unicode codepoint + fg color + bg color + pseudographics, from uint32_t to something larger as uint64_t or some custom struct.

It's not something I am very eager to do, for two reasons:

  1. increased RAM usage
  2. expected slowdown on 32-bit platforms due to the extensively used 'hwattr' that would become 64-bit

At the moment, I am more interested in making twin fully Unicode aware: several parts, including the three X11 hw drivers you worked on, are still limited to the first 64k codepoints

Daxiongmao87 commented 2 years ago

Would it be possible to add this as a compile option or would that make it harder to maintain?

cosmos72 commented 2 years ago

Adding as a compile-time option the choice between current 16-color-palette support and truecolor (24-bits) would definitely complicate the code - and thus its maintenance. There are two reasons:

  1. clearly, the source code would need to support both color formats, with compile-time switch between them
  2. also, twin tries to keep compatibility between different versions and programs compiled with different compile-time options

The latter means you may have a client (for example, twdisplay or twterm) compiled with the old 16-color-palette support communicating with a server compiled with truecolor (24-bits) support - or vice versa. Such interoperability would require adding runtime detection and conversion between color formats.