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: use of `mouse-face' to delimit text zones [was: bidi-display-reordering is now non-nil by default] Date: Tue, 23 Aug 2011 19:15:56 +0300 Message-ID: <834o18hznn.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> <87ipppjfiq.fsf@gmail.com> <87ei0cjvow.fsf@gmail.com> <77465C28555E49ACA714C9A439EA4396@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1314116184 16898 80.91.229.12 (23 Aug 2011 16:16:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2011 16:16:24 +0000 (UTC) Cc: stepnem@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 23 18:16:20 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 1QvteE-0006o2-Nu for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 18:16:18 +0200 Original-Received: from localhost ([::1]:56325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvteE-0000HI-84 for ged-emacs-devel@m.gmane.org; Tue, 23 Aug 2011 12:16:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvteA-0000FY-Sx for emacs-devel@gnu.org; Tue, 23 Aug 2011 12:16:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvte9-0004iu-Ra for emacs-devel@gnu.org; Tue, 23 Aug 2011 12:16:14 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:62297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvte9-0004in-Ij for emacs-devel@gnu.org; Tue, 23 Aug 2011 12:16:13 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LQE00B002DDZ200@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 23 Aug 2011 19:15:54 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.219.41]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LQE00BX52IH9SC0@a-mtaout20.012.net.il>; Tue, 23 Aug 2011 19:15:54 +0300 (IDT) In-reply-to: <77465C28555E49ACA714C9A439EA4396@us.oracle.com> 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:143542 Archived-At: > From: "Drew Adams" > Date: Tue, 23 Aug 2011 08:29:22 -0700 > Cc: 'Eli Zaretskii' , emacs-devel@gnu.org > > 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,... > [...] > 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. Heavy use of this doesn't yet make it right. Good (read: "non-kludgey") programming practices should not use for some feature symbols whose name or documentation give no clue of such a use. Should I count the number of bugs submitted by you in the name of this same principle? The documentation of mouse-face says: `mouse-face' This property is used instead of `face' when the mouse is on or near the character. For this purpose, "near" means that all text between the character and where the mouse is have the same `mouse-face' property value. That's it. Not a word about potential use of that for doing anything else besides displaying the text. How is Joe R. Hacker supposed to know that adding invisible characters to a portion of text covered by mouse-face will break completion?? Btw, mouse-face can also be put on overlay strings and display strings; how can you get the underlying text then? IT'S A KLUDGE!!! > 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. Like what? > And tomorrow you or someone else might make the same argument about any new > property we introduced to delimit candidates. If the face is called `completion-candidate', who would "make the same argument"?