GNU bug report logs - #13686
24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

Previous Next

Full log

Message #101 received at 13686 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: David Koppelman <koppel <at> ece.lsu.edu>, Drew Adams <drew.adams <at> oracle.com>,
	13686 <at> debbugs.gnu.org
Subject: Re: bug#13686: hi-yellow vs. hi-lock-1
Date: Mon, 08 Apr 2013 11:01:07 +0530

Stefan Monnier <monnier <at> iro.umontreal.ca> 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.

----------------------------------------------------------------

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.