GNU bug report logs - #27403
26.0.50; Indentation misalignment with Unicode code points >65535

Previous Next

Full log

Message #35 received at 27403 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 27403 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, adam.niederer <at> gmail.com
Subject: Re: bug#27403: 26.0.50; Indentation misalignment with Unicode code
 points >65535
Date: Fri, 04 Feb 2022 09:05:48 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Andreas Schwab <schwab <at> linux-m68k.org>,  27403 <at> debbugs.gnu.org,
>   adam.niederer <at> gmail.com
> Date: Thu, 03 Feb 2022 21:25:03 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > OK, then why did you say the data was outdated?
> >> 
> >> Because it was.
> >
> > Where's the up-to-date data we could use?
> 
> I don't know either -- the character is still wide in Unicode 14.

I'm guessing Andreas meant the data of the other characters, not of
this one.

The current width data (5½ years later) is up-to-date with the latest
Unicode Standard version, at least AFAIK.  If someone finds a
mismatch, please point out specific discrepancies.

> In the fonts I use, it's definitely wide.  But so is ☺, which is marked
> as narrow.
> 
> So ❓

I don't see how this can be solved as long as indentation works in
columns.  If some font produces a glyph whose width isn't anywhere
close to the Unicode width specifications, what can we do except tell
people not to use those fonts?

Alternatively, if it turns out that most fonts use different width, we
could amend our char-width table to be consistent with those fonts.

Finally, users who aren't happy with either solution could customize
the char-width table in their own Emacs, it's just a char-table that
can be updated.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.