bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41124: 26.3; highlight regexp not working properly - not updating as


From: jan
Subject: bug#41124: 26.3; highlight regexp not working properly - not updating as you type
Date: Thu, 7 May 2020 19:25:04 +0100

I don't understand this reply as I'm very much an emacs user not an
emacs programmer, but "...could query the user whether he still wants
to enable hi-locking using font-lock, with the risk of messing up..."
 - this kind of thing, letting me know I can't have what I'm asking
for (or can but at a risk) would be helpful so I know I'm not going to
get it.
I reported this as a bug out of ignorance, some hint from emacs that
it was PEBKAC[0] would have saved me wasting Eli's time.

jan

[0] <http://catb.org/jargon/html/P/PEBKAC.html>





On 07/05/2020, Michael Heerdegen <michael_heerdegen@web.de> wrote:
> jan via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> First ensure font-lock mode is on. Prefix arg forces it on.
>>
>>    C-u 1 M-x font-lock-mode
>>
>> Minibuffer says font lock mode is enabled
>
> @jan: The test that hi-lock uses internally is actually
>
>   (and font-lock-mode (font-lock-specified-p major-mode))
>
> so you need an implemented font-locking in your buffer.  I guess this is
> intentional and has its reasons.  But yes, it is surprising.
>
> @Eli: the docstring of `hi-lock-mode' just says:
>
> "In buffers where Font Lock mode is enabled, patterns are
> highlighted using font lock."
>
> That's wrong, I think the docstring should be adapted.  _Or_
> hi-lock-mode could query the user whether he still wants to enable
> hi-locking using font-lock, with the risk of messing up other
> highlighting that doesn't come from font-lock.
>
> Michael.
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]