emacs-bidi
[Top][All Lists]
Advanced

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

Re: [emacs-bidi] Suboptimal display-reordering in minibuffer


From: Larry Denenberg
Subject: Re: [emacs-bidi] Suboptimal display-reordering in minibuffer
Date: Mon, 28 Jun 2010 19:07:16 -0400

>What I want to know is, if it wasn't ב followed or preceded by a caret,
>how come Emacs decided to render this paragraph right-to-left?

I'm saying that it *was* ב preceded by a caret.


>> But there's no point in trying.  The buffer can't possibly contain an
>> actual ^ב.  No buffer can.  Buffers and strings can contain only those
>> characters encodable in 22 bits.  If your input facilities permit, you
>> can prove this by typing ^Q ^ב; Emacs refuses to insert such a character
>> (Wrong type argument: char-or-string-p, 67110353).
>
>[Character] ^ב is just another Emacs display feature, like ^C.  Emacs
>has special code in its display engine to produce such two-character
>combinations to display an otherwise unprintable character as a string
>that any terminal will show without any problem.  But Emacs still knows
>that these two characters stand for a single character, and "C-u C-x ="
>will tell you which one.

Sorry for being unclear.  Let me rephrase more precisely.

The character ^ב exists.  It is a ב with the 27-th bit set, which is to
say, 1489 + 2^26 = 67110353.  This character can't appear in any Emacs
string or buffer (cf. error message above).

You are correct that sometimes Emacs carefully displays an unprintable
character with a multi-char combination, when there's really only a
single character in the buffer.  That's not happening here.  Here, Emacs
has a character that can't be inserted into a buffer.  So it carefully
inserts a multi-char combination instead.  But in this case, it's *not*
a single character, and C-u C-x = will tell us nothing.  Said another
way:  It's the inserter, not the displayer, that's being careful.

I apologized in a previous note for taking us all down this "display of
control-bet" red herring.  Let me repeat the apology:  I incorrectly
reported bad behavior, and indeed there is no issue.  It doesn't matter
what the directionality of ^ב is, because the bidi routines, which are
responsible for displaying buffer contents, will never see such a
character.  And since the buffer actually contains first caret then ב,
we automatically get the correct behavior in both RTL and LTR modes.

The only conceivable question is whether the ^ב that I see is wrong
because it should be C-ב.  I promise to forget this if you will.

/Larry Denenberg
address@hidden
http://larry.denenberg.com/



reply via email to

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