bug#13686: hi-yellow vs. hi-lock-1

[Jambunathan K <kjambunathan@gmail.com>]

Stefan Monnier <monnier@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.

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