opensubscriber
   Find in this group all groups
 
Unknown more information…

e : emacs-devel@gnu.org 13 November 2010 • 9:51PM -0500

Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
by Eli Zaretskii

REPLY TO AUTHOR
 
REPLY TO GROUP




> From: Kenichi Handa <handa@m17n...>
> Cc: emacs-bidi@gnu...., emacs-devel@gnu....
> Date: Mon, 01 Nov 2010 20:16:57 +0900
>
> And, for tty, as it's impossible to do the same thing as
> graphic terminal, the current code does this:
>
> thin-space: same as empty-box
> hexa-code: display "U+XX", "U+XXXX", "U+XXXXXX" ,
> "E+XXXXXX" depends on the character code (the last
>         one is for a character of code >= #x110000).
> acronym: surround an acronym by "[" and "]" as this:
> "[ZWNJ]", "[LRE]"
>
> At the moment, that is hardcoded in the function
> produce_glyphless_glyph of term.c.
>
> And, for tty, `no-font' means a character not encodable by
> the terminal coding system.

There are a few issues that perhaps need to be fixed:

  . If the default value of terminal-coding-system is nil, glyphless
    character display does not take effect: all the non-ASCII
    characters are displayed as question marks.  I think this is
    because safe_terminal_coding claims it can safely encode any
    character.  This look inconsistent and confusing, so I think we
    should fix that.

  . Composite characters are displayed as question marks regardless of
    the setting of glyphless-char-display-control.  I think this is
    because term.c:produce_composite_glyph does not consider the new
    glyphless-char display feature.  I think users will expect that
    composite characters behave like un-encodable characters on a TTY.


Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.