On Mon, Jun 28, 2010 at 5:14 AM, Larry Denenberg <la...@denenberg.com>wrote:
>
> >The issue is whether we can safely force the echo area messages to
> >_always_ be rendered with left-to-right paragraph direction. This is
> >what you are suggesting, right?
>
> Well, I made several suggestions, of which this was one. Let me flesh
> it out a little bit.
>
> I think the best solution is this: Echo buffers and the minibuffer
> should permit but not enforce bidirectionality, and anyone who writes to
> them must be sensitive to this fact and appropriately careful. If you
> want to echo "X is not defined" as an LTR sentence with X variable, it's
> your job to be sure that X doesn't set the direction to something you
> didn't intend.
>
> The trouble is that zillions of messages were written without bidi in
> mind, and (as we've seen) at least one doesn't do the right thing. So
> what should we do? Check every message and fix all the offenders?
> You first, Indy. In the meantime, what is a reasonable alternative?
>
> And here I will stand by my suggestion for forcing LTR. The reasoning
> is something like this: Emacs messages are written in English, which is
> LTR. They may contain arbitrary text, but that text---even if displayed
> RTL---is essentially in quotes and can't change the directionality.
>
>
My own suggestion was to set the direction according to the language in
LC_MESSAGES ("system-messages-locale" in emacs) if the proper translation is
installed, LTR otherwise. However, a quick search seems to indicate that at
the moment there is no i18n for emacs at all (there is a new i18n project,
but I did not find any code there:
http://savannah.nongnu.org/projects/emacs-i18n ).
Given the above, my suggestion becomes identical to yours: set
directionality to LTR in system messages, possibly leaving an option for the
user to force to RTL in specific messages.
[snipped some arguments, to which I fully agree]
> >Btw, there's something I overlooked before: why exactly is ^ב
> >considered a strong R2L character? Could you please go to it in the "
> >*Echo Area 0/1*" buffer, type "C-u C-x =", and show what Emacs tells
> >about that character?
>
> First of all, I don't think your procedure works. You can make the
> message appear, and with care you can get a cursor on top of it, but
> typing C-u (or most anything else) changes the buffer contents---it's
> not called the Echo Area for nothing! To get your hands on the
> character you'd have to write a function that grabs the contents of the
> buffer and bind it to a key, or in some other way avoid echoing.
>
>
How exactly did you get the ^x?
The echo messages that I see here look like C-x.
Also, I was able to get it in the minibuffer by using the interactive
global-set-key command. Seems like what was inserted in the buffer was
actually "C","-","א".
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). From the manual:
>
> In strings and buffers, the only control characters allowed are
> those that exist in ASCII; but for keyboard input purposes, you can
> turn any character into a control character with `C-'. The
> character codes for these non-ASCII control characters include the
> 2**26 bit as well as the code for the corresponding non-control
> character. Ordinary terminals have no way of generating non-ASCII
> control characters, but you can generate them straightforwardly
> using X and other window systems.
>
> Here's what I think is happening: The code that complains about
> undefined characters handles uninsertable characters (things like ^ב and
> meta-control-mouse-down) by translating them to visible representation.
> So the message contains a real caret followed by ב. That is, the first
> character has no strong directionality, and the directionality is set by
> the second character, a non-control ב.
>
But then the reordering algorithm would have rendered it ב^ and not ^ב as
you saw. Probably the truth is in between - maybe the handling of
uninsertables is done AFTER reordering, so from the POV of the reordering
algorithm it is considered a single character as Eli said.
AA
_______________________________________________
emacs-bidi mailing list
emacs-bidi@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-bidi
