From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Koppelman Newsgroups: gmane.emacs.bugs Subject: bug#13686: hi-yellow vs. hi-lock-1 Date: Wed, 10 Apr 2013 13:33:37 -0500 Message-ID: References: <878v6vidh7.fsf@gmail.com> <7BC00EAA1AF8466D8F9C17B3CA4E82B8@us.oracle.com> <87bob65sbw.fsf@gmail.com> <87wqtkxspi.fsf@gmail.com> <87y5cttwpw.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1365618862 28072 80.91.229.3 (10 Apr 2013 18:34:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Apr 2013 18:34:22 +0000 (UTC) Cc: 13686@debbugs.gnu.org To: Jambunathan K Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 10 20:34:26 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 1UPzqi-0000uH-QL for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Apr 2013 20:34:25 +0200 Original-Received: from localhost ([::1]:54126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPzqi-0001V6-Cj for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Apr 2013 14:34:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPzqd-0001Uo-Q6 for bug-gnu-emacs@gnu.org; Wed, 10 Apr 2013 14:34:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPzqc-0004qK-I3 for bug-gnu-emacs@gnu.org; Wed, 10 Apr 2013 14:34:19 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPzqc-0004qD-Ej for bug-gnu-emacs@gnu.org; Wed, 10 Apr 2013 14:34:18 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UPzuE-0001Wh-Gp for bug-gnu-emacs@gnu.org; Wed, 10 Apr 2013 14:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Koppelman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Apr 2013 18:38: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.13656190455671 (code B ref 13686); Wed, 10 Apr 2013 18:38:02 +0000 Original-Received: (at 13686) by debbugs.gnu.org; 10 Apr 2013 18:37:25 +0000 Original-Received: from localhost ([127.0.0.1]:44017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPztd-0001TP-Fy for submit@debbugs.gnu.org; Wed, 10 Apr 2013 14:37:25 -0400 Original-Received: from ecelsrv1.ece.lsu.edu ([130.39.16.10]:56522) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPztb-0001TB-N7 for 13686@debbugs.gnu.org; Wed, 10 Apr 2013 14:37:25 -0400 Original-Received: from localhost (unknown [127.0.0.1]) by ecelsrv1.ece.lsu.edu (Postfix) with ESMTP id E4AAB28095; Wed, 10 Apr 2013 18:33:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at ece.lsu.edu Original-Received: from ecelsrv1.ece.lsu.edu ([127.0.0.1]) by localhost (ecelsrv1.ece.lsu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6HacZMwD+Qx; Wed, 10 Apr 2013 13:33:37 -0500 (CDT) Original-Received: from sky.ece.lsu.edu (sky.ece.lsu.edu [130.39.96.14]) by ecelsrv1.ece.lsu.edu (Postfix) with ESMTP id 6FE1728081; Wed, 10 Apr 2013 13:33:37 -0500 (CDT) In-Reply-To: <87y5cttwpw.fsf@gmail.com> (Jambunathan K.'s message of "Mon, 08 Apr 2013 11:01:07 +0530") 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:73312 Archived-At: Jambunathan K writes: > Let me propose a new scheme which will work as below. ... I'm not sure I understand the point. I'm pretty sure you are not suggesting that the hi-lock commands be replaced by something like highlight-other-matches to be used after a sequence of facemenu commands. That would be too cumbersome. Stefan's concise face description format sounds reasonable, especially since it could be used in other modes maybe through a function like (concise-face-get-face STR) that creates a new face or returns an existing one. That would avoid loading hi-lock with unneeded complexity. I think there are more useful improvements than face handling that can be made to hi-lock. For example, a way to save highlighting patterns in a separate file. Jambunathan K writes: > Stefan Monnier writes: > >> How 'bout designing a concise "face description" format, so that instead >> of choosing "hi-yellow", the user can choose (say) "b:yellow", >> "f:blue", or "s:bold". This would give access to "any color", and in >> order not to overwhelm the user, the completion would default to only >> completing among a predefined set (corresponding to the current >> predefined faces)? > > I was trying to refine this line of thought. It leads to facemenu.el, > specifically `facemenu-set-foreground' and `facemenu-set-background'. > > Stay with me, as I explain. > > ---------------------------------------------------------------- > > Currently highlighting works as follows: > > 1. Choose a regexp via minibuffer > 2. Choose a face via minibuffer > 3. Decorate the buffer via font lock keywords. > > Let me call this model, "Tell and Do". Highlighting is explicitly > "Told" via minibuffer. > > ---------------------------------------------------------------- > > Let me propose a new scheme which will work as below. > > 1. Mark a word or a symbol under point > C-M-@ > > 2. Decorate region which is but a instance to be highlighted > > M-x facemenu-set-foreground RET > M-x facemenu-set-background RET > M-x facemenu-set-bold RET > & co. > > 3. Highlight > M-s h r or C-x w h. > > Face properties used for highlighting will be use results determined > by 2. > > This model is "Show and Tell". Face properties of highlighting are > "Shown" right in the buffer that is edited (as opposed to a minibuffer > prompt) and highlighting library infers the face properties based on > text at point. > > ---------------------------------------------------------------- > > There is a functional parity between `hi-lock-face-defaults' and > `facemenu-listed-faces'. > > ---------------------------------------------------------------- > > Problem statement/Possible way ahead > ==================================== > > Of course facemenu.el, "works" only for certain modes. > > More specifically it works only for those modes that defines a > `facemenu-enable-faces-p'. The notion of persistence of face properties > (as in serializing/encoding face properties in to the edited text) is > "in built" in to facemenu.el. > > I have more ideas on how facemenu.el can play nicely with other > libraries. I will dump my thoughts in a separate bug report. > > ----------------------------------------------------------------