Re: Buffer names with R2L characters

[Stefan Monnier]

> I think that we need a new functions, something like R2L-quote and
> L2R-quote that will produce strings that will not cause problem when
> used in R2L (or L2R) reading direction.

That might be a good idea.  At least it would let us encapsulate the
solution to the problem, so we can change it later on.

>> And second, what do you mean by "zero width"?  The current facilities
>> let me change the LRM display only globally, so I cannot make these
>> LRM characters zero-width only in the mode line -- they will be
>> displayed as such in all the buffers and strings.  Moreover, I'm not
>> sure TTYs support zero-width.
>> Instead, I propose to make the LRM invisible.  This is supported on
>> all display types.

> May be we need 2 LRMs (and 2 RLMs), the normal "real" one, which is part
> of the user text, and a "virtual" one, which is always invisible, ignored
> by search, and never saved. This will solve many problems, but will create
> others. May be use the "virtual" LRM/RLM only on non saved text (like the
> mode-line, dired buffer and so on).

Maybe another way to attack the problem is to say that the < and the >
in that string are not neutral but "weak L2R" or something like that.
Maybe this would also work for XML markup.

We could specify such a thing via some char-table overriding the
default bidi properties of specified chars.  We would either need to be
able to set this as a text-property over the "<N>", or to have one for
the mode-line.

>> > I think Eli is wrong here. An example will help, a file with the
>> > (logical) name "/abc/def GHIK/LMNO qrst" when uniquified will appear
>> > as: "def ONML|KIHG qrst" which is clearly wrong.
>> > My way to solve it is as above, i.e. add zero width LRM on both sides
>> > of the separator (/ or |) in addition to the enclosing LRMs.
>> I think this is beginning to become gross.
> But it is a general solution that is easily implemented.

Indeed, for the buffer names it seems perfectly acceptable since we
generate them ourselves and they don't go very far.  I'm not sure why
Eli doesn't like this solution.


        Stefan