Whoosh, you missed the point. I've used xterm for decades and never used any of that.
If those operations turn into "no-op" or perform the minimum rendering change, it is still valid xterm escape processing. There is a difference betwen parsing an escape sequence, and performing a discrete & specific action for it. You are trying to say an escape sequence must render it exactly like a real xterm would. For example, that the double underline should show a double underline, it cannot show an underline, and if it doesn't, then I guess it should not be parsed? And create a mess? I think that's not right. The display operation can be exactly the same as another. ALL of the various highlight requests could be parsed, and then ALL of them could do inverse video, and it be a valid xterm *parser*. It is the parsing issue that matters for progress converting to xterm default. Discrete maximum eyecandy is not as concerning but you are treating that as critical. If all these changes bloat the kernel size, or bloats the number of #ifdef SMALL_KERNEL required to make our install media work, then your position is quite different from the "switch to xterm" goals. Crystal Kolipe <kolip...@exoticsilicon.com> wrote: > On Tue, Jan 31, 2023 at 12:03:53AM +0100, Christian Weisgerber wrote: > > Crystal Kolipe: > > > > > Here is the latest version of the double underline and strikeout parts of > > > my > > > console patchset. > > > > I'm sorry, but I gotta ask: Who or what uses something like this?? > > It's useful on displays that lack other forms of attributes, such as a low- > resolution monochrome LCD. If you can't do bold, dim, or colour. > > And I mean, obviously something like ssdfb(4) is not going to run X very well, > is it? > > > Offhand, I don't even know if xterm can do it. > > It can, but at smaller font sizes it looks the same as single underline. > > echo '^[[21This is double underlined' > > > If you want this > > kind of typographic detail, shouldn't you be using a graphics canvas > > rather than a character-cell terminal? > > Why? The console already supports 'attributes', such as bold and > underlining. Why would necessarily we want one and not another? > > The original idea behind this patchset was to bring wscons to the point where > the default emulation can change from vt220 to xterm. That has very obvious > advantages, and I'm assuming that you wouldn't automatically be against such > a change. > > But if we're about to tell people, 'OK, now you can set TERM=xterm, and gain > improved performance on the console', then users are going to notice > features that xterm provides, but that wscons does not. > > I'm creating sample implementations of the xterm features that I and my > collegues here use in the first instance. Whether any particular one is > deemed to be suitable or appropriate to include in OpenBSD is an open > question. > > But at least you've got code to try. > > I've been using 256 colours, strikeout, dim, invisible, true bold, italic, > and more on the console for the last few weeks, (some of it for longer), and > personally I think it's useful in email clients, status reporting scripts, > and more. >
