[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Wed, 24 Aug 2011 10:51:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> Switch to buffer: a{data.tex,foo.ada,*scratch*}
>> so maybe the {,,,} list should use bidi-string-mark-left-to-right before
>> the comma.
> They should probably run each completion candidate through
> bidi-string-mark-left-to-right, yes.

That was my impression as well.

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

> So perhaps we should have a more comprehensive plan for handling these
> issues before we start sprinkling bidi-string-mark-left-to-right all
> over the place.

Sounds fine to me, yes.  I don't think there's any hurry to try and
address all these issues before 24.1.

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?

> It is also possible we should add a more general bidi-string-mark-dwim
> function, which uses either LRM or RLM depending on the paragraph
> direction, to avoid additional changes later, when the UI will be
> localizable.

Yes, that's what I was getting at, basically I think that we almost
never want to add a LRM but instead we want to add some kind of
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).

> > > Need your decision on the space spec.
> > Is the above enough, or are there still more open issues?
> If the above is a "go ahead" for 24.1, then no open issues left.

Yes, it's a "go ahead" for the "treat any `space' display property as
a segment separator".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]