GNU bug report logs -
#76852
30.1; Regression in whitespace-mode causes display issue under terminal
Previous Next
Reported by: 张海 <dreaming.in.code.zh <at> gmail.com>
Date: Sat, 8 Mar 2025 06:54:01 UTC
Severity: normal
Found in version 30.1
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: 张海 <dreaming.in.code.zh <at> gmail.com>
> Date: Wed, 12 Mar 2025 23:49:17 -0700
> Cc: 76852 <at> debbugs.gnu.org
>
> > The change was intentional, but it follows the Unicode data tables, so
> > evidently some characters which were previously half-width because
> > full-width by default in Emacs 30. Thus, the NEWS text is indeed
> > slightly misleading.
>
> Does that mean the solution should be users who use a CJK locale will
> need to set cjk-ambiguous-chars-are-wide to nil in order for
> whitespace-mode to work?
Not necessarily. I still haven't decided what would be the best
solution for that, but telling users to sett
cjk-ambiguous-chars-are-wide to nil for the benefit of whitespace-mode
is definitely not high on the list, because the effects of that
variable are global on the entire Emacs session. I'm asking these
questions in order to understand better the issues and the possible
solutions.
Currently, the two solution I'm pondering are:
. remove from the list of ambiguous-width characters some of the
characters with low Unicode codepoints, including the 2 characters
used by whitespace-mode, on the assumption that these characters
are unlikely to be full-width in fonts used by Emacs users in CJK
locales
. change the default of cjk-ambiguous-chars-are-wide to nil, on
the assumption that most users in CJK locales use fonts where
these characters have half-width glyphs
> > Hmm... does gnome-console have any configuration options for this? It
> > sounds like it assumes these characters are half-width regardless of
> > what the font does. This URL:
> >
> > https://superuser.com/questions/573876/how-to-let-gnome-terminal-to-use-specific-font-to-display-punctuations-in-their
> >
> > seems to imply you should be able to control this aspect of the
> > terminal.
>
> I can confirm this does allow the middle dot to show up as two
> characters wide (even without a font change), which looks strange but
> does make line wrapping and editing work.
OK, so in any case, we should extend the doc string of
cjk-ambiguous-chars-are-wide to mention the possible need to customize
the terminal emulator to draw the ambiguous-width characters according
to the font that is actually being used.
Thanks. Let me think a bit more about what would be the best
solution. But could you tell which font you used that has full-width
glyphs for these characters? Is it unusual to use that font for
terminal emulators in CJK locales? I'm wondering why we didn't hear
by now complaints from CJK users about the effects of
cjk-ambiguous-chars-are-wide other than on whitespace-mode. Maybe the
other ambiguous-width characters are seldom used in practice? Or
maybe too little time has passed since Emacs 30 was released?
This bug report was last modified 58 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.