[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13686: hi-yellow vs. hi-lock-1
From: |
David Koppelman |
Subject: |
bug#13686: hi-yellow vs. hi-lock-1 |
Date: |
Wed, 10 Apr 2013 13:33:37 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
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.
>
> ----------------------------------------------------------------