GNU bug report logs - #3452
23.0.94; display

Previous Next

Full log

Message #62 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 3452 <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: Re: bug#3452: 23.0.94; display
Date: Mon, 08 Jun 2009 04:44:50 -0400

> From: Kenichi Handa <handa <at> m17n.org>
> CC: 3452 <at> emacsbugs.donarmstrong.com, cyd <at> stupidchicken.com
> Date: Mon, 08 Jun 2009 17:10:27 +0900
> 
> Not for U+202D, but such combining characters as U+0300 are
> treated correctly by xterm (not by gnome-terminal).
> 
> > > To conclude, I think there's not that much we can do for
> > > this situation.  I think the current behaviour of
> > > gnome-terminal (displaying standalone U+202D as a space of
> > > width 1) is a bug.
> 
> > If other terminals behave correctly, I would agree.  But if not,
> > perhaps we need to work around this, if possible.  For example, we
> > could have an entry in display tables for these characters.
> 
> It seems xterm, gnome-terminal, GNU/Linux console, and
> mlterm treat U+202D as spacing character, but, Konsole
> (KDE's terminal) and kterm treats it as non-spacing
> character.

Wasn't gnome-terminal the one that started this bug report?  And you
even tell above that gnome-terminal does NOT treat U+202D correctly.
So which terminals do?

If xterm, the Linux console and mlterm do work, then maybe your
suggestion to do nothing is good enough.

Btw, what do you think about my idea to add a display table entry for
these characters?

Previous Next

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