Re: bidi-display-reordering is now non-nil by default

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > I say "probably" because there's a separate but related issue with
>> > buffer and file names that include R2L characters and end in weak or
>> > neutral characters: those weak or neutrals will be displayed to the
>> > left of the R2L characters, as in "DCBA!" (instead of the more
>> > plausible "!DCBA"), and appending the LRM will not cure that.
>> I'm a bit confused here: you say "to the left of the R2L characters",
>> but your example shows it to the right.
> Yes, I meant the other left ;-)
>> This said, it seems the problem you're referring to is a lot more
>> general than to icomplete/ido/iswitchb: the same problem will show up
>> wherever the file/buffer is displayed, no?
> Yes, but with buffer/file contents it's a different story.

I meant buffer/file *name*, sorry.
But I think I now understand the problem you're talking about:
ABCD! all on its own would be properly displayed as !DCBA, but if it is
followed by an LRM mark then it will turn into DCBA!.  So, yes, that's
a problem.  What about adding a TAB instead of an LRM?

>  emacs -Q
>  M-: (read-buffer "Buffer name: " "אבגדה") RET
>  M-n

Right.  This is one more example of a "field".  I think we'd want
a function like bidi-independent-string which takes a string STR and
returns a new string that displays just like STR does but with the added
twist that none of the surrounding text will ever get displayed in the
middle of STR and that text that comes after STR gets displayed "after"
and text that comes before gets displayed "before".
I'm not sure if that is possible or even meaningful, tho.

>> E.g. I think that a buffer ABC<1> should be either displayed as CBA<1>
>> or <1>CBA depending on the surrounding text direction (which might be
>> different from the paragraph direction).
> If not, what do you mean by "surrounding text direction"?

Whether this ABC<1> appears within an L2R chunk of text or an L2R chunk
of text.  I guess that "paragraph direction" is a good approximation.

>> Yes, it's a "go ahead" for the "treat any `space' display property as
>> a segment separator".
> Well, in light of the above, it sounds like we need to treat such
> properties as a paragraph separator, to get the effect we need.  I'll
> take a stab at that.

Thanks,


        Stefan