On Sat, Jan 07, 2023 at 11:09:00AM +0000, Nicholas Marriott wrote: > As far as SGR 38/48 with anything except 2 and 5 goes - the only terminals > I have at hand do not discard but I think either of discarding or not > discarding would be reasonable. What does xterm do here? It would probably > be best to do the same.
Xterm only ignores the unknown argument immediately following the 38/48, but interprets the rest. So SGR 38;9;1m sets bold. I've changed my code to do the same. > On terminals with fewer than 256 colours, I think the sequence should > probably do nothing. I've seen one program that uses it when colours <= 8, but that seems to have been an oversight. > I would be inclined to just ignore bold together with 256 colours (that is, > don't make bold change anything) as the terminal only supports bright and > not true bold. Hummm. That would break existing behaviour in a few cases. Although most users are not seeing colour at all on the console, anyone who has set TERM=pccon currently has working bold in programs that parse terminfo. Also there are obviously programs that just assume ansi sequences are recognised. Bold is such an old and basic attribute that it's pretty reasonable to assume that it is implemented somehow on any modern terminal that implements any ansi sequences. > Making an alternative colour map which is brighter would be > possible, although I haven't seen any terminals that do that. That's interesting. Although it would be nicer to have a real bold font. Maybe just printing the exising font twice, offset one pixel to the right would work for that? Regarding 256 colour support in general, this is very much a late addition to the whole project of making the console usable with the xterm terminfo entry. I'm quite enthusiastic about adding it now, but if it's going to make the original goal of s/vt220/xterm in /etc/ttys less attractive because it causes breakage in obscure corner cases, then I can always drop the 256 colour part. Although to be honest, I think that the rest of the patchset without the 256 colour support is already very close to being usable. Even as it is, it's an overall improvement because it fixes several exising bugs. In any case, I'll post an updated version with 256 in an hour or so.