GNU bug report logs - #79145
31.0.50; doc-view-mode with auto-revert-mode emitting message when it shouldn't

Previous Next

Full log

Message #35 received at 79145 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: jforst.mailman <at> gmail.com, 79145 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#79145: 31.0.50; doc-view-mode with auto-revert-mode
 emitting message when it shouldn't
Date: Thu, 07 Aug 2025 21:55:56 +0300

> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,   jforst.mailman <at> gmail.com,
>    79145 <at> debbugs.gnu.org
> Date: Thu, 07 Aug 2025 20:42:19 +0200
> 
> >> I think I'd prefer the general-mechanism solution.  Would someone
> >> like to work on a patch along those lines?
> >
> > I could work on the general mechanism. Which variant do you prefer,
> > extending revert-buffer-in-progress-p or a new
> > auto-revert-buffer-in-progress-p?
> 
> I have the feeling that such a solution would be overkill.

How can a single variable be overkill?

> Let me explain:
> 
> As Jake has clarified, he's not strictly opposing all messages relating
> to non-current buffers but this doc-view message is problematic
> especially because it advertises a key-binding which only has the
> advertised effect in a doc-view buffer.  So I guess we could simply
> guard that message with something like
> 
>   (when (get-buffer-window (current-buffer) (selected-frame))
>     (message ...))
> 
> or probably better
> 
>   (let ((inhibit-message (get-buffer-window
>                           (current-buffer) (selected-frame))))
>     (message ...))
> 
> so that it's still logged in *Messages* which would be a less drastical
> change.

But it was you yourself who claimed that the problem is more general
than just the above.  Did you now change your mind?  Or what did I
miss?

> If we'd really like to have an option which says "don't bother me with
> messages relating to buffers which are not current (or visible)", then
> auto-revert is just one out of several possible causes.  Timers are
> another one, e.g., messages from Gnus fetching mail.  Or modes doing
> asynchronous communication.  And then one probably wants to be able to
> define that certain messages are fine although the corresponding buffer
> isn't current/visible ("You have 3 new mails", "The compilation of foo
> has finished") but others not...

So now you are saying that even solving this for all auto-revert
clients is not general enough?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.