Some programs will always ignore terminfo and make their own guesses, that's just the nature of terminfo, not much to be done about it.
I meant ignore bold in combination with 256 colours, not ignore it entirely. But if you can come up with some scheme to display it then go for it. If possible can you now give me your latest patches without 256 colours and I will test them and see if we can get them in. Probably best to split them into three: new escape sequences, additional key sequences, and bug fixes to existing code. On Sat, 7 Jan 2023, 12:05 Crystal Kolipe, <kolip...@exoticsilicon.com> wrote: > 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. >
