Re: Buffer names with R2L characters

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Mon, 20 Jun 2011 14:00:34 -0400
> 
> > 2>FEDCBA>
> 
> Sounds like the same kind of issue as the one brought up a while ago
> about bidi+XML (or any other mark up).

It's caused by the bidirectional properties of the '<' and '>'
characters, but other than that, this has nothing to do with XML.

> Another important case is when you use uniquify (in which case the
> above will happen less frequently since file buffers add the directory
> info to disambiguate the name, but may be replace by similar problems
> if the separator between the file and directory part (typically /, or
> \, or |) doesn't have the "right" bidi behavior).

You get something like foo/bar/FEDCBA, so there's no problem here, I
think.

> > I verified this with the Unicode Reference Implementation, and there's
> > no bug in bidi.c: this is the correct reordering according to the
> > Unicode Bidirectional Algorithm.
> 
> > appending a suitable character to the end of the string (after the
> > numeric tail) and making it invisible with text properties.  But this
> 
> Hmm, I would have expected that adding something at the end of the string
> would not work ("too late"), whereas adding it between "ABCDEF" and
> "<2>" would have felt very natural to me.

The final "resolved level" of a weak character depends on characters
on its both sides, not just on one side.  So there's no "too late".

When '>' is the last character, the algorithm uses a default value for
the absent character after it, and the default depends on the current
paragraph direction, which must be L2R both in the mode line and in
buffer-menu.  Thus, '>' gets the (default) L2R direction in this case.
Appending a zero makes '>' be surrounded by two digits, so it gets the
R2L direction (because the digits are embedded in a run of R2L
characters) and is mirrored into '<'.