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

[Stefan Monnier]

>> I guess this brings us back to "a way to mark some char as a field
>> separator, just like a TAB; and in this particular case it clearly would
>> be fine to do it via a `display' property.
>> Some might even argue that a (space :align-to ...) display property is
>> sufficiently similar to a TAB that such a property should be interpreted
>> similarly to a field separator by the bidi reordering code.
> Only :align-to, or any other properties supported by the `space'
> display spec?

Good question.

> If only the former, why only that?

At least the :align-to has a clear similarity to the TAB char.

> Why not :width, for example?

I wouldn't know.  That's the problem.  I guess it would be a heuristic
in any case, so we'd want to provide some way to control the behavior in
case the heuristic is wrong.

>> Assuming it's not straightforward to change the C code to handle such
>> display properties (not simple enough for 24.1, or maybe we're not sure
>> it's actually a good idea to do it)
> It wouldn't be hard to add this feature, if you think it's okay to do
> that now, the feature freeze notwithstanding.  I would need the answer
> to the question above, though.

Maybe all `space' display properties should be treated as field
separators, but with a new :not-a-bidi-field-separator property
that can override this default.

Not sure which way the default should go, since OT1H I tend to feel like
the default should be to treat such spaces as field separators, based on
their similarity to TAB and based on the current way they're used in
tabulated data, but OTOH maybe this is a reflection of the lack of R2L
support until now.

>> >> can you tell whether other completion facilities in Emacs might need
>> >> similar changes?
>> I'd tend to think that most/all other completion facilities should be
>> fixed by using the generic code rather than by fixing their code, so
>> they shouldn't need similar changes.
> "Generic code" meaning treating a `space' display spec as a segment
> separator?

No, "generic code" meaning the "built-in" completion code in
minibuffer.el, as opposed to alternative completion packages that may
re-implement all or part of the completion code (ido, iswitchb,
auto-complete, company-mode, ...).

> In any case, please humor me by giving the list of completion packages
> outside of minibuffer.el, as my knowledge of this area barely covers
> the standard completion facilities.

For Emacs-24, I've made an effort to try and reduce the amount of
alternative completion code (most of which was not like
ido/iswitchb/.. but more like lisp-mode or makefile-mode
re-implementing the simple completion code already implemented for the
minibuffer), so I guess that nowadays there's mostly just ido and iswitchb
bundled with Emacs plus company-mode in the GNU ELPA (hopefully soon
accompanied with auto-complete and completion-ui).


        Stefan