[Top][All Lists]
[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.
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/11/01
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/11/01
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/11/01
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM,
Eli Zaretskii <=
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/11/17
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/11/17
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/11/17
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/11/17
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/11/13
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/11/13
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/11/16
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/11/17
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Andreas Schwab, 2010/11/17
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/11/17
- Prev by Date:
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
- Next by Date:
Re: elpa.gnu.org (Stale archive-contents?)
- Previous by thread:
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
- Next by thread:
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
- Index(es):