Re: Buffer names with R2L characters

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: James Cloos <cloos@jhcloos.com>,
>     emacs-devel@gnu.org
> Date: Tue, 21 Jun 2011 13:26:50 +0900
> 
> Eli Zaretskii writes:
>  > > From: James Cloos <cloos@jhcloos.com>
>  > > Cc: Eli Zaretskii <eliz@gnu.org>
>  > > 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.
> 
> Please rethink here, Eli.  In the sense Jim is talking about, at the
> conceptual level this use case is indeed markup, ie, metadata encoded
> in plain text.  There may be better ways of solving the display
> problem than taking that literally.

Well, the fact that I started this discussion is a sign that I'm
willing to rethink ;-)

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.  If you
disagree, then please explain why this use of <..> should be
considered markup.  Just the fact that it uses <..> is not enough,
IMO.

>  > 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.
> 
> Of course this is true, but it misses his point, which is that in a
> markup context, there is text data (in SGML, CDATA or PCDATA) and
> there is metadata.  From the point of view of working with these
> higher-level protocols, it may desirable that each run of text data be
> treated separately in an editor.

And it will be, when Emacs is taught to reorder non-plain text.  I
never said nor thought that we should reorder markup text as if it
were plain text -- that'd be terribly wrong.  Similarly, we should
reorder only comments and strings while displaying program source
files.  Both these use cases call for selectively reordering an
otherwise strictly L2R text.  Emacs should be able to do that, and in
doing so it will need to rely heavily on the buffer's major mode.

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

Moreover, I'm not sure it would be a good idea to use such an
infrastructure for FOO<2> buffer names even if it were available.  If
you agree with me that <2> is not markup, then using methods designed
for markup languages would be as kludgey as appending an invisible
character: they both use a trick not intended for this use case.
There's no major mode here to help us DTRT with a string that is part
of the mode line.

> There's nothing in the Unicode standard that says that Emacs couldn't
> have a `non-bidi' syntax class, which when applied as a property to
> text in a buffer would break that buffer into two or more bidi
> "streams" to which the algorithm would be applied independently.

Right.  I didn't mean to say otherwise.

> 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 ;-)