From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Tue, 23 Aug 2011 21:14:28 +0200 Message-ID: <87aab0j5yj.fsf@gmail.com> 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> <87ipppjfiq.fsf@gmail.com> <87ei0cjvow.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1314127183 27214 80.91.229.12 (23 Aug 2011 19:19:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2011 19:19:43 +0000 (UTC) Cc: Eli Zaretskii , 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:19:39 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 1QvwVe-0001OJ-13 for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 21:19:38 +0200 Original-Received: from localhost ([::1]:41755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvwVd-0003Uk-8N for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 15:19:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvwVb-0003R5-0q for emacs-devel@gnu.org; Tue, 23 Aug 2011 15:19:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvwVa-0006VS-2I for emacs-devel@gnu.org; Tue, 23 Aug 2011 15:19:34 -0400 Original-Received: from mail-fx0-f41.google.com ([209.85.161.41]:39377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvwVY-0006V9-9Y; Tue, 23 Aug 2011 15:19:32 -0400 Original-Received: by fxg9 with SMTP id 9so572744fxg.0 for ; Tue, 23 Aug 2011 12:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=tw6/0Ac9OmvvNSRITaLjsqvqi1Ogmhy80Roqk4pizpo=; b=w3dbWgdnlbB+a35uYOnpEQHbjG4oed2jwEHEI8DZkmN2OYYyw2/XwcJ4B7WokOQlJv YQ7ljgeh32UH39ikm+N76xWdgtKVlg2RRFmkQgxMIdwbAiyxyuTZQybjY57CZ2M0O306 ALf8AKkRF08htaaaoePYR+qeSRQvLfxpSIPRU= Original-Received: by 10.223.75.154 with SMTP id y26mr5961577faj.104.1314127170387; Tue, 23 Aug 2011 12:19:30 -0700 (PDT) Original-Received: from localhost (176.119.broadband10.iol.cz [90.177.119.176]) by mx.google.com with ESMTPS id b14sm211354fak.5.2011.08.23.12.19.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Aug 2011 12:19:29 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Tue, 23 Aug 2011 14:24:56 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.161.41 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:143552 Archived-At: On Tue, 23 Aug 2011 20:24:56 +0200 Stefan Monnier wrote: >> I think I've gathered as much from the fact that the bug is still >> unfixed. Which is precisely why I used this precious opportunity to >> point out that there might be more reasons. So now there's also the fact >> that using the face for this seems like a kludge to Eli (and possibly >> others? certainly me included) and gets in the way of other unrelated >> code (or at least makes certain "obvious" solutions "non-obvious"). > > Actually, changing it so that another property is added to delimit the > text wouldn't solve your problem: the mouse-face property would > still also be added and would hence still interfere with your use. I don't think so. As explained in the bug thread, the problem for me is that custom text properties (specifically mouse-face in my case) added to the completion annotations are clobbered. I don't care about the face of the completion items (although I'd argue they should respect user additions as well). The argument you raised against not clobbering the annotations additions and thus allowing face like mouse-face for them was that the completions code would get confused, because that property is used to delimit completion items. This argument would disappear if that was fixed and a separate (non-face) property was used instead. --=20 =C5=A0t=C4=9Bp=C3=A1n