emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Tue, 23 Aug 2011 22:03:47 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Tue, 23 Aug 2011 14:19:37 -0400
> 
> >> 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.

I think they all do.  And the implementation is the same: we produce
white space of the specified dimensions.

Btw, I've looked at all the users of (space :SOMETHING) spec in
Emacs.  Almost all of them use :align-to.  The rest all use :width,
and with a single exception (ruler-mode, which uses this on the
fringes, and so is irrelevant to this discussion), all of them use
this to separate and align fields.

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

If we want to keep this simple enough to get into 24.1, I suggest to
treat them all as segment separators, and not introduce any overriding
properties until someone comes with a convincing use case that
actually needs something like that.

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

Thanks, I will take a look.

Need your decision on the space spec.



reply via email to

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