From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Tue, 23 Aug 2011 22:03:47 +0300 Message-ID: <831uwchrvw.fsf@gnu.org> References: <4E48D309.6050503@acdlabs.ru> <83hb5jujjs.fsf@gnu.org> <874o1j10zv.fsf@fencepost.gnu.org> <8362lyvcli.fsf@gnu.org> <83k4aasnm9.fsf@gnu.org> <838vqmx9tj.fsf@gnu.org> <83ei0cimdl.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1314126237 20753 80.91.229.12 (23 Aug 2011 19:03:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2011 19:03:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 23 21:03:51 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QvwGN-0003EE-1O for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 21:03:51 +0200 Original-Received: from localhost ([::1]:42061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvwGM-0004vF-JV for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 15:03:50 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvwGK-0004uD-9b for emacs-devel@gnu.org; Tue, 23 Aug 2011 15:03:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvwGI-0002rK-Mq for emacs-devel@gnu.org; Tue, 23 Aug 2011 15:03:48 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:56897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvwGI-0002qQ-CS for emacs-devel@gnu.org; Tue, 23 Aug 2011 15:03:46 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LQE00D00A7LOR00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 23 Aug 2011 22:03:44 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.219.41]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LQE00D3WAA83MB0@a-mtaout20.012.net.il>; Tue, 23 Aug 2011 22:03:44 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143550 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > 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.