From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11095: [PATCH] Re: bug#11095: 24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment? Date: Tue, 4 Dec 2012 14:43:53 -0800 Message-ID: <82F792DC51D24C39AEBFEE9BC6CBE335@us.oracle.com> References: <81d37z271c.fsf@gmail.com> <87626i2i4r.fsf@gmail.com><61B14D03B48D4D9E998771D3B7E4252C@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1354661109 27650 80.91.229.3 (4 Dec 2012 22:45:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Dec 2012 22:45:09 +0000 (UTC) Cc: 11095@debbugs.gnu.org, 'Jambunathan K' To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 04 23:45:21 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tg1Eu-0003zC-4C for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Dec 2012 23:45:20 +0100 Original-Received: from localhost ([::1]:57879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tg1Ei-0002kG-6x for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Dec 2012 17:45:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tg1Ea-0002hM-Bc for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2012 17:45:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tg1EY-0004f6-W7 for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2012 17:45:00 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tg1EY-0004f1-QP for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2012 17:44:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tg1Ec-0006wU-8Q for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2012 17:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Dec 2012 22:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 11095-submit@debbugs.gnu.org id=B11095.135466104926605 (code B ref 11095); Tue, 04 Dec 2012 22:45:02 +0000 Original-Received: (at 11095) by debbugs.gnu.org; 4 Dec 2012 22:44:09 +0000 Original-Received: from localhost ([127.0.0.1]:53784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg1Dk-0006v3-M5 for submit@debbugs.gnu.org; Tue, 04 Dec 2012 17:44:09 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:38277) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg1Di-0006uv-22 for 11095@debbugs.gnu.org; Tue, 04 Dec 2012 17:44:07 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB4MhxDq027289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2012 22:44:00 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qB4MhwYS014800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2012 22:43:59 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qB4Mhwrc004550; Tue, 4 Dec 2012 16:43:58 -0600 Original-Received: from dradamslap1 (/10.159.232.171) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Dec 2012 14:43:58 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac3Sak8n098H8YROQyOmFyVGg9CP8wAAQsZA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67927 Archived-At: > >> > -(defface hi-yellow > >> > +(defface hi-lock-1 > >> I'm not sure it's an improvement. When choosing a face in > >> hi-lock-face-buffer, "hi-lock-1" doesn't speak much to me > >> contrary to "hi-yellow". > > > > Not specifically related to this face, but it is a bad > > idea, in general (no doubt there are exceptions), for a > > face name to advertize particular face attributes, such > > as the color. > > Depends. I too suggested that it depends. But it depends on what "depends" means ;-). I.e., depends on what? The dependence I see is that there could be exceptions where the purpose/use/meaning of the face is in fact related to a particular color. > In the present case, the face has no particular purpose, So in particular, it is NOT related to any particular color, including yellow. > so saying that "its purpose to highlight in yellow" doesn't > sound like such a bad idea. That makes as much sense (to me) as to say that its name should be `hi-lock-rumpelstiltskin". Unless it is true that it really always should "highlight in yellow", regardless of the face's current color. If all we can say is that this face is about highlighting, then the only operative word is "highlight". If we can be more specific - e.g., highlighting like a marker pen, then that's what is called for. In `highlight.el', for instance, I have a command for highlighting text by dragging the mouse over it, like using a marker pen, aka a highlighter. That command is called `hlt-highlighter' (it can use any face, like all `hlt-*' commands). If `hl-lock-yellow' were intended for this kind of highlighting then you might call it `hl-lock-highlighter' or some such. I have no idea what `hl-lock-yellow' is really for. You yourself have just said that its use has nothing to do with "yellow", however. > Not really worse than "its purpose is to be number 2". Is its purpose really "to highlight in yellow"? You seem to say no, above. But if so then you probably don't need to define a customizable face for that. Just highlight in yellow. Or if the color must always be (or is always intended to be) yellow, but users can customize other face attributes, then using "yellow" in the name would make sense. In that case, the doc string should say something about this restriction/intention wrt the color being constant. > > The color is presumably something that the user can > > customize, and is typically not something that speaks > > to the use or meaning of the face. > > "2" doesn't "speak to the use or meaning of the face" very > much either. You didn't hear me argue in favor of using `2' here. Those are presumably not the only two choices: 2 vs yellow. On the other hand, if absolutely nothing can be said about this face other than it is one of N hi-lock faces (none of which we can say anything else about), then `2' is better than nothing. It is certainly better than being overly specific and misleading, and doubly certainly better than suggesting a specific face attribute such as a particular color. `hi-lock-2' does not suggest that any particular face attribute has the value `2', unless it is something like a box line width of 2 pixels. `hi-lock-yellow' misleads immediately, suggesting that the face always has the color yellow. > I think the real issue here is that hi-lock should have a customizable > set of faces rather than a set of customizable faces. > So if the user doesn't like hi-yellow (which should be called > hi-lock-yellow, BTW) because she never highlights in yellow, she can > replace it with her own face with the name she likes. Ah, in that case you are really talking, I think, about having one or more user options, which each has a face (or a set of faces) as value. I don't see how that is related to the above, however. If you call such an option `*-yellow' then its name would still be misleading, no? And if on the other hand you feel that `hi-lock-2' is OK as an option name here, but not as a face name, then I don't follow the logic. Just why would you prefer a "customizable set of faces" over a "set of customizable faces"? And how does that relate to the names?