Re: [emacs-bidi] adding LRM in visual-to-logical transform

[Eli Zaretskii]

> Date: Mon, 19 Nov 2001 22:28:04 +0200
> From: "Ehud Karni" <address@hidden>
> 
> On Mon, 19 Nov 2001 21:59:37 +0200, Eli Zaretskii <address@hidden> wrote:
> > > 
> > > The only fool proof sulotion is to use "visual" search (and even then
> > > there are problems if lines are broken).
> > 
> > Doesn't visual search help only when you see the text on the screen?
> > Otherwise, I'd imagine we will have the same problems, because it's
> > not trivial to know how a given logical text will be displayed.
> 
> May be we have misunderstanding here. By "visual" I mean the conversion
> of the buffer to its "visual" order and then searching.

That's what I had in mind as well.

> The user has no problem to know what she is searching for because
> she sees the searched string in the mini-buffer.

I usually don't look at the minibuffer when I search.  I just type
the text I want to find and look at the window where the current
buffer is displayed.

With visual-order buffers, this is a problem, since you need to
mentally convert the text into the visual order before you type.  That
conversion might not be very easy, except in very trivial cases, given
the subtleties we were discussing here.

By contrast, since the ``normal'' typing order is the logical order,
this problem doesn't happen with logical-order buffers.

Of course, we've been there many times in the past, when we discussed
whether the buffers should be stored in logical or in visual order.

> For real user confusion I'll use regular
> expression search (even limited). If the normal search (which the user
> sees only the visual order) and is done on the logical order (like it 
> is done on M$Windows) is confusing, then reg-exp search will look like
> something unpredictable whenever it will include Hebrew and digits.

Regexps have many complications when you move to Unicode (assuming we
want to support whatever UTR#18 says we should).  We are nowhere near
addressing that complexity.