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#13686: hi-yellow vs. hi-lock-1 Date: Tue, 26 Feb 2013 16:33:24 -0800 Message-ID: <7BC00EAA1AF8466D8F9C17B3CA4E82B8@us.oracle.com> References: <878v6vidh7.fsf@gmail.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 1361925260 2191 80.91.229.3 (27 Feb 2013 00:34:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Feb 2013 00:34:20 +0000 (UTC) To: "'David Koppelman'" , <13686@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 27 01:34:41 2013 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 1UAUyn-0007yl-9Y for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Feb 2013 01:34:41 +0100 Original-Received: from localhost ([::1]:45515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAUyS-0003By-DZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Feb 2013 19:34:20 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAUyP-0003Bn-9U for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 19:34:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAUyN-0002yv-6w for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 19:34:17 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAUyN-0002yc-24 for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 19:34:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UAV06-0002bn-28 for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 19:36: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: Wed, 27 Feb 2013 00:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13686 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13686-submit@debbugs.gnu.org id=B13686.13619253229976 (code B ref 13686); Wed, 27 Feb 2013 00:36:02 +0000 Original-Received: (at 13686) by debbugs.gnu.org; 27 Feb 2013 00:35:22 +0000 Original-Received: from localhost ([127.0.0.1]:51943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAUzR-0002ar-RY for submit@debbugs.gnu.org; Tue, 26 Feb 2013 19:35:22 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:46606) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAUzP-0002ai-2A for 13686@debbugs.gnu.org; Tue, 26 Feb 2013 19:35:20 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1R0XTxo003653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Feb 2013 00:33:30 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1R0XTCP001992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 00:33:29 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1R0XSR6006566; Tue, 26 Feb 2013 18:33:28 -0600 Original-Received: from dradamslap1 (/10.159.140.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Feb 2013 16:33:28 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac4UdrvQ6gleZriYTZC+EGzIG4wM5AABSYrA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:71872 Archived-At: The face name should not reflect any particular face attributes - not, that is, unless the attributes are somehow made to remain relatively constant (e.g. always some shade of yellow). Or if there is only one face for a given feature/library, and there is no more appropriate name, then it can make sense to name the face after the feature/library, for purposes of discoverability etc. The main point is that it makes little sense for a face, which is a variable thingy (changeable, customizable), to have a name that suggests otherwise, i.e., suggests that it has some _particular_, constant quality. The face name should reflect what the face is for - the kind of highlighting or whatever that it does. Is this all we can say about the purpose of this face? > The user's goal is to highlight something That's pretty vague, but at least "highlight" presumably belongs in the name. (No, not all faces are for highlighting.) And if you can narrow down the kind of "something" or the use of the highlghting, then that info too can help. Presumably, this highlighting of something is hi-lock highlighting. That already makes it a specific kind of highlighting. There is a specific way to turn it on/off etc. The manual says that hi-lock-mode highlights text that matches a regexp you provide. Is this face used for that highlighting? If so, and if there is not some other hi-lock face that it could be confused with, then "hi-lock" in the face name is the best identification of what it is for: it is the face for hi-lock highlighting. If hi-lock uses other faces that are not for highlighting, then add "highlight" to the name. If hi-lock has multiple faces used for highlighting in essentially the same way, i.e., there is nothing other than their separateness that distinguishes them, then yes, "hi-lock-1", "hi-lock-2", etc. are the best names. IOW, if you cannot be more specific than to say that this is for hi-lock highlighting, then hi-lock highlighting is what the name should reflect. It certainly should not reflect the face's particular default attributes, whether they be underlining, boxing, or a yellow background. > the user can go through face choices until he or she finds > a suitable color (if the first one does not satisfy) By that I guess you mean choosing among the available hi-lock faces, e.g., by cycling. Nothing wrong with that. But the current appearance of each of those faces has nothing to do with the face names you currently use: "hi-green" etc. Face `hi-green' might well mean italic blue text on a pink background and wrapped in a box. You seem to be arguing that a name like "hi-green" helps the user by suggesting the appearance (e.g. green background or foreground) s?he will get. Nothing could be farther from the truth. It misleads the user into thinking precisely that. If you want to give the user names that describe appearance, then you don't want faces, which are variable, you want constants - e.g., symbols or strings. In that case, let users choose a _color name_ for each kind of highlighting that you make available, and set the color of the face for that highlighting to the chosen color. Simple. The user sees color names as the choices (and all available color names, not just 5 or 6). In that case, you need to decide which attribute(s) of the face to use that color for: foreground, background, underline, box. Or you need to somehow let users choose the attribute(s) too.