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 11:05:10 +0300 Message-ID: <83ei0cimdl.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1314086735 19789 80.91.229.12 (23 Aug 2011 08:05:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2011 08:05:35 +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 10:05:31 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 1QvlzH-0006HT-9p for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 10:05:31 +0200 Original-Received: from localhost ([::1]:36482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvlzB-00067K-D3 for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 04:05:25 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvlz6-00066F-Ac for emacs-devel@gnu.org; Tue, 23 Aug 2011 04:05:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvlz1-0007U6-U5 for emacs-devel@gnu.org; Tue, 23 Aug 2011 04:05:20 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:53699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvlz1-0007Tq-Nf for emacs-devel@gnu.org; Tue, 23 Aug 2011 04:05:15 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LQD00500FR9GP00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 23 Aug 2011 11:05:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.219.41]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LQD005CCFSJFA10@a-mtaout20.012.net.il>; Tue, 23 Aug 2011 11:05:08 +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:143530 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Mon, 22 Aug 2011 15:35:24 -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? If only the former, why only that? Why not :width, for example? > 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. > >> 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? If that's not what you meant, I don't understand what other generic solution would be possible. 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.