Re: Buffer names with R2L characters

[Eli Zaretskii]

> Date: Tue, 21 Jun 2011 20:59:51 +0300
> From: "Ehud Karni" <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>         address@hidden, address@hidden
> 
> 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.

Patches are welcome.

> > 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.

The "never saved" part might need some new infrastructure, because the
only one we have -- overlays -- does not affect reordering.

Another idea would be to cover the real string with an overlay with
display property that is a string computed from the covered text, and
put the directional formatting codes in that display string.

> May be use the "virtual" LRM/RLM only on non saved text (like the
> mode-line, dired buffer and so on).

Dired buffer can be saved, e.g. by write-region etc.

Note that these decorations will have to be used in various additional
places, like the prompt displayed by read-buffer ("(defalt FOOBAR)"),
for example.

> > > 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.

I think it's gross, but I won't object to patches to that effect.