GNU bug report logs - #3452
23.0.94; display

Previous Next

Package: emacs;

Reported by: rms <at> gnu.org

Date: Wed, 3 Jun 2009 03:00:03 UTC

Severity: serious

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>, 3452 <at> debbugs.gnu.org
Cc: handa <at> m17n.org
Subject: bug#3452: 23.0.94; display
Date: Sun, 07 Jun 2009 05:16:05 -0400
> From: Chong Yidong <cyd <at> stupidchicken.com>
> Date: Sat, 06 Jun 2009 23:47:26 -0400
> Cc: 3452 <at> emacsbugs.donarmstrong.com
> Reply-To: Chong Yidong <cyd <at> stupidchicken.com>, 3452 <at> emacsbugs.donarmstrong.com
> 
> Sure enough, if I do
> 
>   (aset char-width-table #x202d 1)
> 
> then the screen corruption goes away.
> 
> Maybe we should reconsider setting these characters to have zero-width
> for char-width-table in characters.el, since fill-gstring-body seems to
> handle zero-width compositions poorly.  WDYT?

I think it would be a bad idea to set these characters to anything but
zero width.  These characters are not supposed to be displayed at all,
they have no meaningful glyphs to show them.  They are just directives
to the bidirectional display engines about how to convert logical
order of characters to visual order.

Not to mention the fact that the Unicode standard explicitly calls
them zero-width.

We should find a different way to handle this problem.

Btw, I don't understand how these characters are related to
compositions.  They should not be composed with anything, they always
stand for themselves.



This bug report was last modified 15 years and 153 days ago.

Previous Next


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