From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.bugs Subject: bug#13686: hi-yellow vs. hi-lock-1 Date: Wed, 27 Feb 2013 09:06:02 +0530 Message-ID: <87fw0i5syl.fsf@gmail.com> References: <878v6vidh7.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361936239 29909 80.91.229.3 (27 Feb 2013 03:37:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Feb 2013 03:37:19 +0000 (UTC) Cc: 13686@debbugs.gnu.org To: David Koppelman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 27 04:37:42 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 1UAXpt-0000Yz-2o for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Feb 2013 04:37:41 +0100 Original-Received: from localhost ([::1]:39870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAXpY-0005Wq-3b for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Feb 2013 22:37:20 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAXpU-0005WN-Ke for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 22:37:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAXpT-0004FD-5E for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 22:37:16 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAXpT-0004F9-2D for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 22:37:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UAXrC-0006ox-Vz for bug-gnu-emacs@gnu.org; Tue, 26 Feb 2013 22:39:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jambunathan K Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Feb 2013 03:39: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.136193630526085 (code B ref 13686); Wed, 27 Feb 2013 03:39:02 +0000 Original-Received: (at 13686) by debbugs.gnu.org; 27 Feb 2013 03:38:25 +0000 Original-Received: from localhost ([127.0.0.1]:52108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAXqb-0006mg-4Y for submit@debbugs.gnu.org; Tue, 26 Feb 2013 22:38:25 -0500 Original-Received: from mail-pb0-f48.google.com ([209.85.160.48]:43649) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAXqY-0006mX-6O for 13686@debbugs.gnu.org; Tue, 26 Feb 2013 22:38:23 -0500 Original-Received: by mail-pb0-f48.google.com with SMTP id wy12so82462pbc.21 for <13686@debbugs.gnu.org>; Tue, 26 Feb 2013 19:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=AQJ5qDeP25GLlYyc02FMR4nAk05iZxRcU89QAXbdPtU=; b=sDDHkKJmQvX3iZxuF2oLzRXn6JURtehLkJVyFNuIdKeLoPhfuAraJ//gD7wPoLcyWk 2AfreBYsx+lu+EnQCg6Br5nGvXfV3J/oGhy9sDHI56domZGOqThondgCZbbSIhuztRPB PCjzwtneb/hC0FY2okOgAkStZZjp3yRBKipdt9jmcFm4FY5PMPG7QVra4qVnpF+DvdVt jrBs/EDmwMYP88wTaAwUIH4xpZ3hmJp3ndaWuNlVTnFOxuq0kZy1t/cJ2EPBkciC5brb Nh+/gyPxkwXa0kspbNXM0Bkw13nbjYlnYxCLveD4e5GOqoPIXQyvSDHxfryIg1QUYRxh V8AA== X-Received: by 10.68.217.164 with SMTP id oz4mr1110084pbc.73.1361936192937; Tue, 26 Feb 2013 19:36:32 -0800 (PST) Original-Received: from debian-6.05 ([115.241.8.157]) by mx.google.com with ESMTPS id i10sm3037046pbd.1.2013.02.26.19.36.29 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Tue, 26 Feb 2013 19:36:31 -0800 (PST) In-Reply-To: (David Koppelman's message of "Tue, 26 Feb 2013 17:11:11 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 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:71879 Archived-At: David Koppelman writes: > As the original developer of hi-lock and one willing to continue > maintaining it, let me add my voice: > > I feel that a face name like hi-lock-1 would be much less useful, even > if the name itself were rendered with the highlighting. The user's > goal is to highlight something, currently the user can go through > face choices until he or she finds a suitable color (if the first one > does not satisfy). A cryptic name like hi-lock-1 just puts irrelevant > information in front of the user, assuming the name is highlighted > with the color. New option `hi-lock-auto-select-face' makes selection of faces redundant. So with auto-selection on, one doesn't even have to pick. One merely gets on with one's business of making sense of code/text at hand. Here is my original use-case ,---- http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11095 | | 2) Make `hi-lock-face-buffer' use a different face on each invocation. | | Here is a real-world usecase for the above request. | | As a programmer, I use highlighting to trace variable dependencies | within a function. For example, in the example below, after | highlighting the variables in __different__ faces, I will come to the | conclusion that "a" depends on "d" and "tmp". | | c = d; | b = c + tmp; | a = b; | | And I use this very often to track variables and how they get their | values from. | | If I were to use the default Emacs provided behaviour then I would | have to press M-n multiple times as I highlight more and more | symbols. (Typically I have 3-5 symbols highlighted before I turn off | highlighting.) | `---- > A name like font-lock-comment-face is semantic because it indicates > the purpose of the face. The purpose of hi-yellow is to highlight > something in yellow, so in that sense the name is semantic. In would consider `hi-yellow' a "constant" face. I am not questioning the usefulness or rationale of original choice - I am convinced that it is useful. I am merely presenting one another use-case. We can have both constant faces and themable faces. IIRC, my original patch defaliased the hi-yellow to hi-lock-1. > If themers felt a strong need, we could make hi-lock-face-defaults > themable so that hi-yellow and hi-green say, could be replaced with > hi-golden-honey and hi-grassy-green. (Or the original face names with > slightly different tints.) This seems like a half-hearted attempt at theming. Remember, `highlight' face which is one of the "core" faces. My suggestion could be considered as a case for augmenting the highlighting faces with more numbers and have someone who is "visually adept" choose good defaults. The need for theming - that is multiple highlighting faces to *co-exist simulataneously* in one's buffer - is very important. When I have 3-4 highlights in my buffer (using the current defaults) my eye hurts. Bottomline: It is not an "one-or-the-other" proposal. Let's have best of both worlds. --