Re: Buffer names with R2L characters

[Eli Zaretskii]

> From: James Cloos <address@hidden>
> Cc: Eli Zaretskii <address@hidden>
> Date: Mon, 20 Jun 2011 16:13:15 -0400
> 
> The bidi algorithm is just not designed for markup (and the <digits> tag
> /is/ markup).

No, it isn't.  Not every use of '<' and '>' is markup.  They can also
be used in context such as "n > N" etc.  They are just characters; XML
did not appropriate them just because it uses them for markup.

> Ideally there would be a 0-width break before the <digits>

It's possible (we could use LRM), but it isn't ideal, because text
terminals will have trouble displaying it.  That's why I think using a
character covered by invisible text property is better.

> or a way to mark the <digits> blob as non-neutral.

This feature is still far away.  I thought about it, and concluded
that implementing it is not trivial, or at least there were a couple
of problems for which I couldn't think of a good solution yet.

I don't think we should wait for such a feature and in the meantime
display "12>FEDCBA>" as buffer name.  I'd like to have a solution,
even if an interim one, for Emacs 24.1.

> Whether the result should display as <12>FEDCBA, <21>FEDCBA or FEDCBA<12>,
> though, I have no idea.

We can decide whatever we want (but not the one with "21": the order
of digits in a number should be left to right).  But any of these
needs "help" to get them look like that, because the UBA simply cannot
treat these cases gracefully.

> I presume that a ordering break would result in the third.

What's an "ordering break"?

> For that to work the engine obviously needs to know what markup looks like,
> which requires additional meta information about each document.  The buffer
> mode helps, but may not be sufficient?

The Emacs reordering engine doesn't know anything about major modes,
text properties, overlays, and other meta information.  The only
exceptions are (1) `display' properties and (2) buffer narrowing
limits.  This design is intentional, because otherwise the same code
could not be used for reordering text independently of redisplay,
e.g. for producing visual-order encodings, like if you wanted to print
R2L text on a relatively dumb printer or send it to a process that
doesn't grok bidi.