On Mon, Jan 30, 2023 at 04:53:02PM -0700, Theo de Raadt wrote: > 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.
No, I am certainly not saying that. > 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. Of course it's not right. Especially for the attributes, (such as double underline), which are _not_ defined in the xterm terminfo entry. Because programs which parse terminfo should not assume that they are available. Attributes which _are_ defined in xterm terminfo, if we don't render those, then programs which rightlyfully expect them to be rendered might 'create a mess': E.G. an email program tries to display a deleted email using strike through, and the text is actually all the same instead of being diferentiated. That gives a bad user experience. There is a difference between saying that we support a fair subset of xterm sequences, and saying that what is defined in the xterm terminfo works adequately on wscons. The two are not the same. > 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*. Yes, I agree. The VGA driver does a similar thing, substituting light blue for underline. > 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. No I am not. I wrote the patches for rendering these attributes for internal use, and am sharing them because they are related to the other console changes. > 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. With what has already been committed, TERM=xterm already works better than TERM=vt220. Once the f-keys hunks went in, then it would be better than TERM=pccon as well. I have already been using TERM=xterm for a month, without most of the 'eyecandy' patches. So I think that the first goal has already been achieved. At least on my machines it has. But just because the original goal is well within sight, I didn't see that as a reason to stop.
