On Thu, 2021-04-15 at 14:20 +0200, Martijn van Duren wrote:
> I did some archeology today and found that it used to behave as
> non-printable, but it got broken in release 334 (august 2018), when
> CharWidth was introduced. Before that my_wcwidth was used directly.
>
> Since there doesn't appear t
I did some archeology today and found that it used to behave as
non-printable, but it got broken in release 334 (august 2018), when
CharWidth was introduced. Before that my_wcwidth was used directly.
Since there doesn't appear to be a repository with commit messages I'm
not 100% sure why this macr
Since the discussion seems to have died out, I take my patch will not be
accepted.
The decision appears to be that OpenBSD is right and everyone else is wrong in
this matter. Given that, and the calls to change the behavior of other OSes and
terminal emulators around SHY: are you going to at least
On Wed, 2021-04-14 at 20:10 +0300, Lauri Tirkkonen wrote:
> Since the discussion seems to have died out, I take my patch will not be
> accepted.
>
> The decision appears to be that OpenBSD is right and everyone else is wrong in
> this matter. Given that, and the calls to change the behavior of oth
On Tue, Apr 06 2021 11:27:21 +0100, Stuart Henderson wrote:
> Some terminal emulators are using iso-8859-1 semantics of soft hyphen,
> unicode did things differently but those terminals haven't changed.
>
> xterm printed as hyphen
> mltermprinted as hyphen
> putty p
On Tue, Apr 06 2021 13:09:11 +0200, Martijn van Duren wrote:
> On Thu, 2021-04-01 at 10:39 +0300, Lauri Tirkkonen wrote:
> > On Thu, Apr 01 2021 09:30:36 +0200, Martijn van Duren wrote:
> > > However, based on the description by the Unicode Consortium I think
> > > OpenBSD does the right thing and
On Tue, 2021-04-06 at 13:27 +0100, Stuart Henderson wrote:
> On 2021/04/06 13:09, Martijn van Duren wrote:
> > I´m also not convinced that the other wcwidth implementations might be
> > on to something and that the unicode consortium is having inertia
> > problems.
>
> The difficulty is that it is
On 2021/04/06 13:09, Martijn van Duren wrote:
> I´m also not convinced that the other wcwidth implementations might be
> on to something and that the unicode consortium is having inertia
> problems.
The difficulty is that it isn't *possible* to give a single correct
answer for the width of SHY, it
On Mon, 2021-04-05 at 20:30 +0200, Ingo Schwarze wrote:
> Hi,
>
> Martijn van Duren wrote on Thu, Apr 01, 2021 at 09:30:36AM +0200:
> > 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 Pos
On Thu, 2021-04-01 at 10:39 +0300, Lauri Tirkkonen wrote:
> On Thu, Apr 01 2021 09:30:36 +0200, Martijn van Duren wrote:
> > However, based on the description by the Unicode Consortium I think
> > OpenBSD does the right thing and xterm and others should be fixed,
>
> practically, I doubt this will
On 2021/04/05 12:45, Theo de Raadt wrote:
> 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
Hi Ingo,
On Mon, Apr 05 2021 20:30:39 +0200, Ingo Schwarze wrote:
> 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, o
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
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 modul
On Thu, Apr 01 2021 09:30:36 +0200, Martijn van Duren wrote:
> However, based on the description by the Unicode Consortium I think
> OpenBSD does the right thing and xterm and others should be fixed,
practically, I doubt this will happen. I don't think the glibc people will be
convinced to break c
When using terminal software on non-OpenBSD to connect to my OpenBSD IRC
machine, I noticed that sometimes the local terminal disagrees with the remote
tmux and application (in this case, irssi) about the character width of some
lines, causing different kinds of breakage. Those lines happened to co
When it comes to these discussions I prefer to go back to the standards
and not just looking at the surrounding discussions.
The standard[0] states the following in section 23.2:
Hyphenation. U+00AD soft hyphen (SHY ) indicates an intraword break
point, where aline break is preferred if a word must
17 matches
Mail list logo
