emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
Date: Sat, 13 Nov 2010 15:51:03 +0200

> From: Kenichi Handa <address@hidden>
> Cc: address@hidden, address@hidden
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]