Re: Buffer names with R2L characters

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > However, I'm not sure what you are suggesting to rethink,
 > specifically.  What I said is that in foo<1>, the "<1>" part is not a
 > markup, it's just part of a string that is a buffer name.

Well, it's not markup in the sense of HTML (ie, display markup), but
it is markup in the sense of XML (semantic markup).  It's true that
the appended string is arbitrary, and that the relationship to the
"desired" buffer name is quite arbitrary (you could use alphabetic
characters instead of numerals, for example).  But it is used to
disambiguate what to the user would otherwise be identical names, and
the specific form clearly indicates that this is "metadata".  Buffers
on main.c and main.c~ clearly represent files with different names,
while main.c and main.c<2> by convention represent files with the same
name.  It is this convention, not the use of "<>", that makes the
uniquifer "<1>" into markup.

[Each run of plain text in a markup buffer should be treated as a
separate "stream" of text for bidi display purposes, or something like
that.]

 > And it will be, when Emacs is taught to reorder non-plain text.

OK.

 > I never said nor thought that we should reorder markup text as if
 > it were plain text -- that'd be terribly wrong.

 > But the necessary infrastructure is not yet in Emacs, and it won't be
 > there in time for Emacs 24.1.

OK, that's what I wanted to say myself, but it wasn't clear to me that
was your reasoning.

 > There's no major mode here to help us DTRT with a string that is part
 > of the mode line.

Sure there is, "mode line mode". ;-)  Mode lines have a syntax, and so
do buffer-names (when uniquifying).  The fact there there's no major
mode we use in buffers that's like that is not really relevant.

Of course if you paste a buffer-name into a buffer in some major mode,
you may run into problems.  But that's always the case when changing
syntax models on the same object.

 > > However, this is an implementation detail.  If life is easier if you
 > > consider every textual object (buffer or string) as a single stream to
 > > which the bidi algorithm should be applied, there's nothing wrong with
 > > that, either.
 > 
 > Well, that won't solve the problem of displaying markup languages and
 > program sources, so it cannot be that simple ;-)

That's exactly the kind of thing where (at least for the next year or
so) I'm just gonna have to trust you. :-)