Re: UTR#9 - Unicode BiDi (was Re: OpenOffice BiDi kudos)

> Date: Mon, 13 Oct 2003 20:04:57 +0200
> From: "Ehud Karni" <[email protected]>
> > >
> > > I guess we will need to get used to type RLM and LRM in similar
> > > situations, since we must be UAX#9 compliant, and since UAX#9 results
> > > in such madness in quite a few cases like this, sigh.
> >
> > I guess you know the answer:  Use U+2010 HYPHEN instead of U+002D
> > HYPHEN-MUNUS.
> 
> Your both missing the point.

I don't think so.

> The user will do as she sees fit so the
> the text she is typing will appear as she likes it. The problem is with
> automatic text generated from stored data (reports), catalog numbers,
> legacy data and internationalization/localization (which connects
> predefined strings with dynamic data).

That's true, but what we need to make sure, first and foremost, is
that such text looks the same in any bidi-aware text processor.  If
the same text looks different in each one of them, we are bringing
chaos on our users.

> Adding formating characters or using strange UNICODE characters will
> produce major problem for searches (Since the same visual display can
> be produced by several Logical strings).

If the user is educated to always type RLM (or LRM, as the case may
be) in such situations, both in the buffer and as the search string,
search will not present any problems.  (The user will want to type
RLM/LRM in the search string to make it display correctly.)  If not,
it's a problem we need to solve somehow anyway, since the fact that
logical <-> visual relation is not 1-to-1 will not be affected whether
we use RLM and its ilk or not.  We could, for example, use some fuzzy
variant of search or something like that.

In other words, to me, the use of these marks is simply the easiest
way of telling Emacs to dwim wrt display and at the same time making
sure that any other UAX#9-compliant processor will dwim.  Look at the
directional marks as some control character you'd type into a word
processor to tell it not to change the direction of display.  E.g., an
extra space in the venerable EinsteinWriter word processor was used
for similar purposes.

> I say that the standard must be changed and improved before it is too
> late (and the time is running out fast).

Do we really have the power to change that?  I doubt that.