[Top][All Lists]

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

Re: [emacs-bidi] Bidirectional editing in Emacs -- main design decisions

From: Eli Zaretskii
Subject: Re: [emacs-bidi] Bidirectional editing in Emacs -- main design decisions
Date: Sat, 10 Oct 2009 20:33:24 +0200

> From: James Cloos <address@hidden>
> Cc: address@hidden,  address@hidden
> Thanks for posting that.  It is a great summary of the concerns and
> needs of an editor when dealing with bidi test.

Thanks, but I think it's just the beginning.  There are lots of other
issues to deal with; see, for example, the aspects of search described
by Ehud Karni in this thread.

The hard problem in making these decisions was to become convinced
that all those other issues are reasonably solvable based on these
basic features, without actually solving any of them.

> Of those points, all but #6 are no brainers; your choices are exactly
> what an editor must do.

Thanks for confirming that.

> Point six is an interesting problem; I'm also unaware of any prior
> art.  I suspect that in the long term it would be best to note the
> start and end directionality of such chunks of text and set them
> chunk-by-chunk in a manner similar to how glyphs are set in the
> absence of such properties.

I think this is impossible in general, because once text is reordered,
the information needed to plug in additional chunks (the resolved
level of each character) is lost.

Note that it is fairly simple to reorder the text of `display' strings
together with the surrounding text -- you just need to feed the
characters together into the reordering engine.  The problem is
elsewhere -- in the code that uses the produced glyphs.

> But in the short term I agree with the choice you outlined.

The future will tell if it was the right decision.  Maybe a useful
first step to examining its validity would be to prepare a fairly
complete list of Emacs applications that currently use the `display'
text properties and overlay properties.  Given such a list, one could
think of their applicability to bidirectional editing, and how the
strings should be displayed in each context to do what the users

reply via email to

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