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

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

[jan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi all,
I've reported the same thing a few years ago, it got fixed pretty fast
but looks like it reverted again.

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

type some text to be highlighted:

  peq
  piq

highlight regexp:

  M-s h r  p[aeiou]q

the above 2 get highlighted as expected

now type some matchable text

  paq

this does not get highlighted.
I expected it should and as I've used this functionality extensively
before, I'm pretty sure it used to work this way.

regards

jan


In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Recent messages:
Font-Lock mode enabled in current buffer
Quit [2 times]
byte-code: No highlighting to remove

Quit [6 times]
Auto-saving...
command-execute: Command attempted to use minibuffer while in minibuffer
Quit [2 times]
Type C-x 1 to delete the help window, C-M-v to scroll help.
Mark saved where search started
Quit [2 times]
Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Text

Minor modes in effect:
  hi-lock-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils eieio-opt speedbar sb-image ezimage dframe find-func help-fns
radix-tree thingatpt hi-lock two-column iso-transl misearch
multi-isearch browse-url url-util elec-pair cl-extra help-mode
autorevert filenotify vc-git diff-mode cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs helm-gtags
subr-x pulse which-func imenu helm-files helm-buffers helm-occur
helm-tags helm-locate helm-grep helm-regexp format-spec helm-utils
helm-help helm-types helm easy-mmode helm-source eieio-compat
helm-multi-match helm-lib async edmacro kmacro desktop frameset
cus-start cus-load finder-inf info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads w32notify w32
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 211611 22413)
 (symbols 48 30035 1)
 (miscs 40 188 361)
 (strings 32 64898 3209)
 (string-bytes 1 1974798)
 (vectors 16 28973)
 (vector-slots 8 763801 9572)
 (floats 8 123 316)
 (intervals 56 2575 0)
 (buffers 992 21))

bug#41124: Acknowledgement (26.3; highlight regexp not working properly - not updating as you type)

[jan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Further, editing the existing highlighted expressions such that they
no longer match the regexp does not un-highlight them

jan

On 07/05/2020, GNU bug Tracking System <help-debbugs@gnu.org> wrote:
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-gnu-emacs@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 41124@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 41124: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41124
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>

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

[Eli Zaretskii]

> Date: Thu, 7 May 2020 12:39:41 +0100
> From: jan via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Further, editing the existing highlighted expressions such that they
> no longer match the regexp does not un-highlight them

Can't reproduce this, either.

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

[Eli Zaretskii]

> Date: Thu, 7 May 2020 12:32:27 +0100
> From: jan via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Hi all,
> I've reported the same thing a few years ago, it got fixed pretty fast
> but looks like it reverted again.
> 
> 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
> 
> type some text to be highlighted:
> 
>   peq
>   piq
> 
> highlight regexp:
> 
>   M-s h r  p[aeiou]q
> 
> the above 2 get highlighted as expected
> 
> now type some matchable text
> 
>   paq
> 
> this does not get highlighted.
> I expected it should and as I've used this functionality extensively
> before, I'm pretty sure it used to work this way.

I cannot reproduce this.

What was the major mode in the buffer where you tried this?  I'm
asking because font-lock-mode is turned on by default, so I don't
understand why you needed to turn it on.  E.g., try repeating the
sequence, without the font-lock-mode command, in *scratch* as soon as
you enter "emacs -Q".

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

[Eli Zaretskii]

[Please keep the bug address on the CC list; use Reply All.]

> From: jan <rtm443x@googlemail.com>
> Date: Thu, 7 May 2020 14:39:28 +0100
> 
> Tried it in windows with -Q
> Works as expected in *scratch*, but create another buffer (C-x b asdf)
> and it does not.

That other buffer is in Fundamental mode, right?  Font-lock does
nothing in Fundamental mode.

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

[jan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,
I don't know much about modes, I'm an emacs user rather than an emacs
programmer. So yep, it was fundamental. I'll do some reading on modes
tonight.

But FWIW I found this originally happening in another mode where I was
trying to identify large chunks easily.
So while this is surely my mistake also, to reproduce, I dragged a.txt
file from a git repo into emacs (again, windows - started with emacs
-Q to be sure)

It said 'git-master' in the status bar.

M-x describe-mode gives

Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Blink-Cursor Diff-Auto-Refine Electric-Indent File-Name-Shadow
Font-Lock Global-Eldoc Global-Font-Lock Line-Number Menu-Bar
Mouse-Wheel Tool-Bar Tooltip Transient-Mark

I can reproduce my 'wrong' behaviour in this text file. I wasn't expecting that.

So FYI and this is surely just my misunderstanding, sorry for messing
you around.

jan



On 07/05/2020, Eli Zaretskii <eliz@gnu.org> wrote:
> [Please keep the bug address on the CC list; use Reply All.]
>
>> From: jan <rtm443x@googlemail.com>
>> Date: Thu, 7 May 2020 14:39:28 +0100
>>
>> Tried it in windows with -Q
>> Works as expected in *scratch*, but create another buffer (C-x b asdf)
>> and it does not.
>
> That other buffer is in Fundamental mode, right?  Font-lock does
> nothing in Fundamental mode.
>

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

[Eli Zaretskii]

> From: jan <rtm443x@googlemail.com>
> Date: Thu, 7 May 2020 16:36:02 +0100
> Cc: 41124@debbugs.gnu.org
> 
> But FWIW I found this originally happening in another mode where I was
> trying to identify large chunks easily.

Which mode was that?

> M-x describe-mode gives
> 
> Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
> Blink-Cursor Diff-Auto-Refine Electric-Indent File-Name-Shadow
> Font-Lock Global-Eldoc Global-Font-Lock Line-Number Menu-Bar
> Mouse-Wheel Tool-Bar Tooltip Transient-Mark

These are minor modes.  The font-lock operation is determined by the
major mode.  You can tell what major mode is active in a buffer with
this:

  M-: major-mode RET

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

[jan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Doing as you say (M-: major-mode RET) it says it is in text-mode.

jan

On 07/05/2020, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: jan <rtm443x@googlemail.com>
>> Date: Thu, 7 May 2020 16:36:02 +0100
>> Cc: 41124@debbugs.gnu.org
>>
>> But FWIW I found this originally happening in another mode where I was
>> trying to identify large chunks easily.
>
> Which mode was that?
>
>> M-x describe-mode gives
>>
>> Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
>> Blink-Cursor Diff-Auto-Refine Electric-Indent File-Name-Shadow
>> Font-Lock Global-Eldoc Global-Font-Lock Line-Number Menu-Bar
>> Mouse-Wheel Tool-Bar Tooltip Transient-Mark
>
> These are minor modes.  The font-lock operation is determined by the
> major mode.  You can tell what major mode is active in a buffer with
> this:
>
>   M-: major-mode RET
>

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

[Eli Zaretskii]

> From: jan <rtm443x@googlemail.com>
> Date: Thu, 7 May 2020 18:32:18 +0100
> Cc: 41124@debbugs.gnu.org
> 
> Doing as you say (M-: major-mode RET) it says it is in text-mode.

Which I think is the same as Fundamental mode wrt font-lock.

You need to be in a major mode that defines font-lock settings.

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

[Michael Heerdegen]

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.

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Thu, 07 May 2020 19:29:25 +0200
> Cc: rtm443x@googlemail.com
> 
> @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.

Please suggest how to say that better.

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

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > @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.
>
> Please suggest how to say that better.

"is implemented and enabled" maybe?  We could also say that Font Lock
mode must be enabled and the MODE must fulfill `font-lock-specified-p'.
Or a combination of those words.

Michael.

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 41124@debbugs.gnu.org,  rtm443x@googlemail.com
> Date: Fri, 08 May 2020 01:12:20 +0200
> 
> "is implemented and enabled" maybe?  We could also say that Font Lock
> mode must be enabled and the MODE must fulfill `font-lock-specified-p'.
> Or a combination of those words.

Thanks, done.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> "is implemented and enabled" maybe?  We could also say that Font Lock
>> mode must be enabled and the MODE must fulfill `font-lock-specified-p'.
>> Or a combination of those words.
>
> Thanks, done.

Skimming this bug report, it seems like this doc fix was all that's
required, so I'm closing this bug report now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[jan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[Eli Zaretskii]

> Cc: 41124@debbugs.gnu.org
> Date: Thu, 7 May 2020 19:25:04 +0100
> From: jan via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 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.

Don't worry about that, you didn't waste mu time.

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

[Michael Heerdegen]

jan <rtm443x@googlemail.com> writes:

> I don't understand this reply as I'm very much an emacs user not an
> emacs programmer,

Sorry for that.

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

What I wanted to say was that your report was totally justified because
what the docstring tells about font-lock mode is a bit misleading.

Maybe hi-lock could also tell you which method of highlighting it
chooses.  And maybe it would also make sense to allow using the
font-lock mode based method in modes that don't implemented font-lock,
I'm not sure.

Michael.