So, your argument is that displays should remain broken forever. > The bug in NetBSD and Linux should be fixed, but that's off-topic here.
If you cannot explain how this problem is going to be fixed (reversed) in these opposing ecosystems (and it is not just Linux and NetBSD), then you've closed the argument with a cop-out. It cannot be off-topic. It is an interop problem which must be settled. >From time to time, defacto standards arise which have inertia that is too great to fight. Your position seems to me that original standard are etched in stone and it is impossible to have new defacto standards arise, and if interop issues arrive, screw everyone -- can't they see there is a stone? The position statement translates simply to: It must remain broken. Ingo Schwarze <schwa...@usta.de> wrote: > Hi, > > Martijn van Duren wrote on Thu, Apr 01, 2021 at 09:30:36AM +0200: > > > When it comes to these discussions I prefer to go back to the standards > > I would propose an even more rigorous stance: not only go back to > the standards, but use whatever the Unicode data files (indirectly, > via the Perl modules) parsed by gen_ctype_utf8.pl specify. Manually > changing properties of individual characters should be restricted > to very rare cases of crystal clear, absolutely unambiguous errors. > When there is the slightest doubt or when there are arguments both > ways, follow the Unicode data files and how Perl interprets them. > > We have > > iswcntrl = 1 because UnicodeData.txt has class Cf (format control char) > iswprint = 1 because the class is neither Cc nor Cs > wcwidth = 0 because the class starts with C (control char) > > This is also neither obviously nor unambiguously wrong, so it should > not be changed. > > The choice of iswcntrl = 1 is most definitely correct because > that's what class Cf says, there can be no doubt about that at all. > Consequently, NetBSD, glibc, and musl are definitely buggy in so far > as they return iswcntrl = 0. > > Whether class Cf is always printable is maybe not absolutely clear. > There are arguments both ways. The stronger argument seems to be > that these format control chars usually appear in the middle of > printable characters and they are printed together with the > surrounding characters. But maybe the FreeBSD argument that > some of them are sometimes not ptinted and hence iswprint = 0 > can also be made, though somewhat dubiously because sometimes > they are printed. Besides, which property would you use for > deciding printability? Please, don't resort to deciding that > character-by-character. > > Whether all control chars are always width 0 can maybe also be > disputed. Again, the stronger argument seems to me that they are. > If they weren't, they would not be control characters but alphanumeric, > punctuation, spaces, or special printable characters, none of which > they are. I say width 1 and 2 require standalone glyphs that are > normally used for the character. Besides, no operating system > correctly identifies this as a control character and yet gives it > width 1. > > I insist that the discussion should remain very strictly formal, > about the properties and classification in the Unicode data files > and nothing else. If people start arguing about what makes sense > for any particular character, that's already an argument going > astray. > > > > So going by this phrase the character should not be printed > > When formatting a document, for example for printing on paper or > the online equivalent like PostScript or PDF, i agree. But i > strongly prefer the terminal to always display this character because > the terminal's usual purpose is not nice text formatting for visual > consumption. It should usually show the full content of strings > or files, be it for inspection or for editing. Omitting characters > in such contexts sets nasty traps for the person working with the > terminal. > > So i say nothing should be changed at all in OpenBSD. > > Yes, that means column counting is wrong on the terminal, but that's > a very minor problem, if it's a problem at all, compared to the havoc > that could result from not showing the character on the terminal at > all, and it cannot be fixed without causing worse problems in situations > that matter more. > > The bug in NetBSD and Linux should be fixed, but that's off-topic here. > > Yours, > Ingo >
