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

[David Koppelman <koppel@ece.lsu.edu>]

Jambunathan K <kjambunathan@gmail.com> 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 <kjambunathan@gmail.com> writes:

> 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.
>
> ----------------------------------------------------------------