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

[Eli Zaretskii]

> Date: Mon, 28 Jun 2010 03:23:34 +0300
> From: Amit Aronovitch <address@hidden>
> Cc: address@hidden, address@hidden
> 
> Would be nice if we would be able to specify the direction explicitly
> (manually) for selected paragraphs in the buffer.

You have that already, see below.

> This can be stored in the
> same way that other metadata (font sizes? color? images?) is being handled.

Emacs is primarily a text editor, and as such, it works with plain
text files.  It doesn't store any metadata when it saves files that
use various faces on display.  Instead, it recreates those faces anew
each time the file is visited and displayed.

The bidi support follows the same basic philosophy of working with
plain text files.  That's why I didn't implement any means of saving
bidi formatting info with the file.  The way of doing what you want is
very simple: insert an LRM or RLM character in front of the
paragraph.  This has the advantage of producing the same effect in any
other bidi-aware application, while being invisible on display, at
least in Emacs.  (And these two characters even have ISO-8859-8
encoding, so you don't even need UTF-8 support in those other apps.)

> > > One of the main reasons. True. But, depending on the bidi reordering
> > > function used, the application might be able to achieve the results by
> > > providing this "higher level choice" itself. With libfribidi, the
> > > "pbase_dir" input parameter can be used for that.
> >
> > In Emacs, we have the bidi-paragraph-direction variable, which
> > overrides the direction determined by the first strong character.
> >
> 
> Is that per-buffer?

Yes.

> What if you want to control directionality of specific paragraphs?

See above.

> (you should be able to do that to properly show bidi text e.g.  in
> w3 mode).

Emacs does not yet handle HTML, XML, and other similar markup formats
with bidi text.  Before we add such support, we need to design it.
UAX#9 is of no help here; we need to come up with our own solution,
preferably one that is based on existing Emacs features.  This is a
significant job, so I put it aside for now.

Btw, I think we should support bidirectional text in comments and
strings in program sources _before_ we support bidirectional HTML.
After all, Emacs is a programmer's editor.  The current plain-text
UAX#9 approach does not work well with, say, C sources that use
bidirectional text in strings and comments.

> > Instead of looking in the code, it is much easier to put the cursor on
> > the ctrl-א thing, and type "C-u C-x =".  Then Emacs will tell you what
> > it thinks about this character, including its codepoint.
> >
> > Could you please do this?  I need to know that in order to understand
> > why Emacs treats this "character" as strong R.  I cannot produce this
> > strange character on MS-Windows, or else I'd do this myself.
> >
> 
> Not sure how to do that. It only appears in the echo area and I cannot
> insert it in a buffer (the message disappears if I try to click the
> minibuffer or move the cursor there using keyboard shortcuts). By the way,
> the message that I see is "C-א not defined", not ^א as Larry described.
> I tried binding the key to self-insert-command, and then I get a regular א
> inserted into the buffer.

You could either (a) look in "*Messages*" or (b) in the two echo-area
buffers, " *Echo Area 0*" and " *Echo Area 1*".  Sorry, I thought it
was clear, given the previous discussions.

> Actually, while typing the above, I realized that while I was trying to bind
> the key, I had C-א appearing in the mini-buffer. Checking, I saw that in
> that scenarion I can actually move the cursor around to it, and use C-u C-x
> =. However, this reveals that the C-א displayed there is actually three
> characters (C, -, א)...

That is what I would expect, but the original issue was with it being
displayed as א^ or ^א.  To me, that says that Emacs did not recognize
this character as having the Ctrl modifier, because then it would have
displayed C-א.