From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: use of `mouse-face' to delimit text zones [was: bidi-display-reordering is now non-nil by default] Date: Tue, 23 Aug 2011 08:29:22 -0700 Message-ID: <77465C28555E49ACA714C9A439EA4396@us.oracle.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1314113390 30113 80.91.229.12 (23 Aug 2011 15:29:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2011 15:29:50 +0000 (UTC) Cc: 'Eli Zaretskii' , emacs-devel@gnu.org To: "=?iso-8859-2?Q?'=A9tep=E1n_Nemec'?=" , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 23 17:29:45 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 1QvsvA-0001rt-84 for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 17:29:44 +0200 Original-Received: from localhost ([::1]:42740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvsv9-0002Go-As for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 11:29:43 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvsv7-0002GY-0b for emacs-devel@gnu.org; Tue, 23 Aug 2011 11:29:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvsv6-000293-1E for emacs-devel@gnu.org; Tue, 23 Aug 2011 11:29:40 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:20696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvsv4-00028o-Bb; Tue, 23 Aug 2011 11:29:38 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7NFTYPR008558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2011 15:29:36 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7NFTVmG019113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 15:29:32 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7NFTOT9021321; Tue, 23 Aug 2011 10:29:25 -0500 Original-Received: from dradamslap1 (/10.159.59.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Aug 2011 08:29:24 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ei0cjvow.fsf@gmail.com> Thread-Index: AcxhfBE9Qo8ZAeXCTumAtcUeT2Ne7QAIzB+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090202.4E53C760.0134,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 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:143540 Archived-At: The question is about whether `mouse-face' should be used only for = highlighting (write-only), or whether it can be good practice to also examine = `mouse-face' boundaries to determine text zones. Eli> I couldn't imagine the mouse-face is used for anything besides the Eli> highlight. Sounds like a kludge to me. And yet `mouse-face' is used here and there throughout Emacs to = determine the boundaries of certain regions of text. If it were used only for = highlighting then you would find only its addition as a text property (i.e., = write-only), almost never its use/testing (e.g., `get-text-property', `next(-single)-char-property'). Grep the Lisp sources for `mouse-face', then check occurrences where we = retrieve that property to determine the boundaries and position of various text "candidates" (e.g. look for `next(-single)-char-property'). We do this = for comint history, Dired, tmm, gnus articles, quail completions,...=20 It is true that in many libraries we only set the property, without ever examining/reading it. But in other libraries we do examine it to = determine boundaries. This is not something new or unusual. > > OTOH bug#8897 is for a use that's pretty far from the=20 > > normal use case of the completion code, so I wouldn't > > make such a significant change just to accomodate this use case. >=20 > now there's also the fact that using the [mouse-face property] > 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"). FWIW, in Icicles, just as in the vanilla Emacs completion code, I make = heavy use of the fact that the `mouse-face' property indicates the boundaries of completion candidates. And in the case of Icicles, completion candidates = are often more complex (various text properties, embedded newline chars = etc.). I grant that perhaps a different text property could be used for = completion candidate delimiting in *Completions*. But I expect it would anyway more or less need to coincide with the = `mouse-face' limits (though I might be missing something - haven't really followed = this thread or =A9t=ECp=E1n's bug report). Candidate layout (vertical, horizontal), cycling, sorting, highlighting, = moving to a candidate in a given position, grabbing a clicked candidate, = drag-selecting multiple candidates, etc. all depend on properly picking up candidate boundaries. Sometimes such operations can be a bit complex. Today, = Icicles, like vanilla Emacs, uses `mouse-face' for that. So I guess I echo what Stefan M. said. Logically I guess a different = text property could be used to delimit candidates, but things might be a lot = more complex if two properties were used or if displayed-text limits did not correspond to the other (new) limits. Not to mention the extra hairiness required for code like Icicles that supports multiple Emacs versions. And tomorrow you or someone else might make the same argument about any = new property we introduced to delimit candidates. Yes, `mouse-face' is doing = double duty currently: highlight + delimit. I'm not convinced that's a bad = thing. I don't see it as a kludge, in any case. All this is just to say that if you're counting voices (Eli + = =A9t=ECp=E1n vs Stefan), count me, a priori, as not keen on abandoning the use of `mouse-face' to = delimit candidates. IOW, +1 for Stefan's reluctance in this regard. [Wrt bug #8897, it sounds from a quick reading like the problem is not = so much with the use of `mouse-face' to delimit completion candidates as it is = with some hard-coding (implicit use) of `mouse-face' within the button code. But = you can ignore this comment, as I have not really followed that thread.]