GNU bug report logs -
#57534
29.0.50; Highlighting lost after auto-revert-mode triggers
Previous Next
To reply to this bug, email your comments to 57534 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57534
; Package
emacs
.
(Thu, 01 Sep 2022 22:41:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dima Kogan <dima <at> secretsauce.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 01 Sep 2022 22:41:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi. I'm seeing this:
1. seq 10 > /tmp/file
2. emacs -Q /tmp/file
3. (highlight-lines-matching-regexp "3")
This is bound to "M-s h l". I see the line containing "3" highlighted
in yellow, as expected
4. M-x auto-revert-mode
5. Back in the shell: seq 20 > /tmp/file
auto-revert-mode kicks in, updating the buffer with the results of 'seq
20' (possibly updating to an empty buffer first, if we react immediately
to the file truncation). At this point I would expect either:
1. The buffer being fully reverted, with all the highlighting
disappearing. This is what happens if we did M-x revert buffer
2. The buffer contents being reverted, but the highlighting being
reapplied
In this auto-revert scenario, we get something in-between: after the
auto-revert hi-lock-interactive-patterns still contains the highlighting
regex, but no highlighting actually happens. It'd be really nice and
useful if the highlighting stayed.
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57534
; Package
emacs
.
(Fri, 02 Sep 2022 06:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 57534 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Thu, 01 Sep 2022 15:40:01 -0700
>
> Hi. I'm seeing this:
>
> 1. seq 10 > /tmp/file
>
> 2. emacs -Q /tmp/file
This "file" is in Fundamental mode, yes? If not, which major mode is
used, and does that major mode turns on Font Lock?
> 3. (highlight-lines-matching-regexp "3")
>
> This is bound to "M-s h l". I see the line containing "3" highlighted
> in yellow, as expected
>
> 4. M-x auto-revert-mode
>
> 5. Back in the shell: seq 20 > /tmp/file
>
>
> auto-revert-mode kicks in, updating the buffer with the results of 'seq
> 20' (possibly updating to an empty buffer first, if we react immediately
> to the file truncation). At this point I would expect either:
>
> 1. The buffer being fully reverted, with all the highlighting
> disappearing. This is what happens if we did M-x revert buffer
>
> 2. The buffer contents being reverted, but the highlighting being
> reapplied
>
> In this auto-revert scenario, we get something in-between: after the
> auto-revert hi-lock-interactive-patterns still contains the highlighting
> regex, but no highlighting actually happens. It'd be really nice and
> useful if the highlighting stayed.
The documentation of hi-lock-mode says:
In buffers where Font Lock mode is enabled, patterns are
highlighted using font lock. In buffers where Font Lock mode is
disabled, patterns are applied using overlays; in this case, the
highlighting will not be updated as you type. The Font Lock mode
is considered \"enabled\" in a buffer if its `major-mode'
causes `font-lock-specified-p' to return non-nil, which means
the major mode specifies support for Font Lock.
If I use your recipe in a file visited with C Mode, which does use
Font Lock, the auto-revert doesn't lose the highlighted lines.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57534
; Package
emacs
.
(Fri, 02 Sep 2022 07:08:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 57534 <at> debbugs.gnu.org (full text, mbox):
>> 3. (highlight-lines-matching-regexp "3")
>>
>> This is bound to "M-s h l". I see the line containing "3" highlighted
>> in yellow, as expected
>>
>> 4. M-x auto-revert-mode
>
> If I use your recipe in a file visited with C Mode, which does use
> Font Lock, the auto-revert doesn't lose the highlighted lines.
However, after manual revert with 'C-x x g' highlighting is still lost.
But this is bug#50431 where 'C-x x g' should be fixed to restore minor modes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57534
; Package
emacs
.
(Fri, 02 Sep 2022 07:22:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 57534 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Dima Kogan <dima <at> secretsauce.net>, 57534 <at> debbugs.gnu.org
> Date: Fri, 02 Sep 2022 10:04:25 +0300
>
> >> 3. (highlight-lines-matching-regexp "3")
> >>
> >> This is bound to "M-s h l". I see the line containing "3" highlighted
> >> in yellow, as expected
> >>
> >> 4. M-x auto-revert-mode
> >
> > If I use your recipe in a file visited with C Mode, which does use
> > Font Lock, the auto-revert doesn't lose the highlighted lines.
>
> However, after manual revert with 'C-x x g' highlighting is still lost.
That's not the same revert as in auto-revert-mode.
> But this is bug#50431 where 'C-x x g' should be fixed to restore minor modes.
I'm not sure this is one of the minor modes to be restored. Maybe
optionally, but not unconditionally. See the discussion in that bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57534
; Package
emacs
.
(Fri, 02 Sep 2022 14:28:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 57534 <at> debbugs.gnu.org (full text, mbox):
> > But this is bug#50431 where 'C-x x g' should be fixed
> > to restore minor modes.
>
> I'm not sure this is one of the minor modes to be restored. Maybe
> optionally, but not unconditionally. See the discussion in that bug.
+2.
Reverting is not about restoring minor modes.
Certainly not blindly so. Not at all.
Reverting is specific to the major mode.
The major mode gets to decide what reverting
means/does. The major mode can decide to
restore whatever it likes, including this or
that minor mode. Nothing should "restore the
minor modes" by default.
My crystal ball whispers that calls for
reverting to "restore minor modes" are trying
to use a sledge hammer where at most a pair
of tweezers might be needed in some uncommon
scenario.
This bug report was last modified 1 year and 234 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.