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: Mon, 08 Apr 2013 11:01:07 +0530 Message-ID: <87y5cttwpw.fsf@gmail.com> References: <878v6vidh7.fsf@gmail.com> <7BC00EAA1AF8466D8F9C17B3CA4E82B8@us.oracle.com> <87bob65sbw.fsf@gmail.com> <87wqtkxspi.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1365445646 3871 80.91.229.3 (8 Apr 2013 18:27:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Apr 2013 18:27:26 +0000 (UTC) Cc: David Koppelman , 13686@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 08 20:27:29 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 1UPGmr-0004Y8-2e for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Apr 2013 20:27:25 +0200 Original-Received: from localhost ([::1]:42582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UP4g5-0002Y8-VP for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Apr 2013 01:31:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UP4g1-0002Xx-U4 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 01:31:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UP4fz-0001HJ-Rm for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 01:31:33 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UP4fz-0001Gl-Nr for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 01:31:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UP4jN-0002p8-Pw for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 01:35:01 -0400 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: Mon, 08 Apr 2013 05:35:01 +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.136539929610843 (code B ref 13686); Mon, 08 Apr 2013 05:35:01 +0000 Original-Received: (at 13686) by debbugs.gnu.org; 8 Apr 2013 05:34:56 +0000 Original-Received: from localhost ([127.0.0.1]:39270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UP4jI-0002oq-75 for submit@debbugs.gnu.org; Mon, 08 Apr 2013 01:34:56 -0400 Original-Received: from mail-pd0-f172.google.com ([209.85.192.172]:62966) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UP4jG-0002oj-5x for 13686@debbugs.gnu.org; Mon, 08 Apr 2013 01:34:55 -0400 Original-Received: by mail-pd0-f172.google.com with SMTP id 5so3055444pdd.17 for <13686@debbugs.gnu.org>; Sun, 07 Apr 2013 22:31:23 -0700 (PDT) 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=tgBKlKqdFLYzYcTj45whzxGlFfuVTmfDLIJrHK5wb1I=; b=O1vB98CtZGtwyTwDoOoGY/Y2Ip4cwj1kBe2KH65XlXyL+bqGMr+oco90ii1hm9CXFG 8XWpjlQfM66xcxYsNkpjs0M1he/d02cZY+pNhGoj4Wn4d8IHOeNU+obUshGDgUT+qFZH RqnywpeYmr+HLsJyX/Hn+5ZAx0R9J4bbtyaMJyFxpiUZJez36O46lNfeABEslaFhFFkE U5CUjvD1qf5UZtE0fPb9dl/yJ4GF5jaxiqxbWmo8dQ6kva1LoRKdSewLnJzigKkYBvnM EF+1Un0DxRRABp9ql6dmLWJWNkvW8mnECB1KTPgBGzLyMJgbbCb09x6zkQZ3VCjMUky+ l7MQ== X-Received: by 10.67.10.228 with SMTP id ed4mr20824588pad.41.1365399082979; Sun, 07 Apr 2013 22:31:22 -0700 (PDT) Original-Received: from debian-6.05 ([101.63.136.209]) by mx.google.com with ESMTPS id xl10sm36284763pac.15.2013.04.07.22.31.18 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Sun, 07 Apr 2013 22:31:22 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 08 Mar 2013 20:33:15 -0500") 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:73257 Archived-At: 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. ----------------------------------------------------------------