GNU bug report logs - #51335
29.0.50; Use warnings facility for reporting Gnus errors

Previous Next

To reply to this bug, email your comments to 51335 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Use warnings facility for reporting Gnus errors
Date: Fri, 22 Oct 2021 10:04:39 -0700

[Message part 1 (text/plain, inline)]

In gnus.user there was a longish conversation about how to better report
the failure of Gnus mail source fetching to the user.

I originally went off on a grand adventure of defining custom errors for
various kinds of Gnus situations, for use in flow control. I still think
that's a good idea, but `nnheader-report' currently does the core of
that job for backend-specific errors, and it's fairly well-developed,
and there's not necessarily anything that needs fixing there.

And the original bug report was more about making errors visible to the
user than flow control, so I went back to that. Apart from fundamental
backend errors, other errors and failures are surfaced with
`gnus-message' and `gnus-error'. Both are gated by the integer value of
`gnus-verbose': higher numbers indicate less-important messages.

The more I fooled with things, the more it looked like improvements
could be made in `gnus-error'. It does a few things:

- Calls `ding'. This function returns nil on my system, dunno if it does
  anything on other systems.
- Displays the error using `message'.
- If the error level is a float, it uses the "float part" as a number of
  seconds to `sit-for' while displaying the error message. So an error
  level 4.5 would (if `gnus-verbose' were 4 or lower) display for 5
  seconds.

So obviously the purpose of this function is to get the user's
attention, in appropriate situations. But `ding' doesn't seem to do
anything, and there are only three places in the Gnus codebase where
`gnus-error' is called with a float value. That means there are only
three places where the `message' isn't immediately swallowed by whatever
comes next (and there's almost always another message coming next),
which really means there are only three places where `gnus-error' does
anything different from `gnus-message'.

The point here was to alert the user to failures in a non-annoying way,
and I think the warnings facility might be a better way of doing that.
`delay-warning', in particular, with a custom warning buffer. The
attached is a code sketch of that. Some points:

- It's hard-coded to prevent buffer pop-up, instead letting the user add
  the buffer to Gnus' window configuration, or call an interactive
  command to see it. We could also do something like put a note in the
  mode-line when there are new log messages to view.
- I've referred to all this as "logging" rather than "warnings", as that
  seems more general.
- gnus-message can also add strings to `gnus-action-message-log', which
  is consulted at the end of startup and maybe displayed with
  `gnus-final-warning'. That only happens once, at startup; it seems
  like a complicated mechanism to only use once. I think this could be
  replaced by warnings.
- Actually I think both `gnus-message' and `gnus-error' could be
  replaced with a `gnus-log' function, but that's something that could
  be played with later on.

I think the main concerns here are making sure the user actually sees
important messages, through a combination of splitting them off into
their own buffer, so they don't get lost in *Messages*, and potentially
delaying display until a particular action is complete, and the user has
a chance to see them.

[gnus-log-warnings.diff (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Sun, 24 Oct 2021 20:37:40 +0200

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> - Calls `ding'. This function returns nil on my system, dunno if it does
>   anything on other systems.

(ding) gives a beep and/or flashes the "visual bell", but many people
has switched off both -- so you get neither.

> That means there are only
> three places where the `message' isn't immediately swallowed by whatever
> comes next (and there's almost always another message coming next),
> which really means there are only three places where `gnus-error' does
> anything different from `gnus-message'.

Well, it depends on how you've configured your messaging level...

> I think the main concerns here are making sure the user actually sees
> important messages, through a combination of splitting them off into
> their own buffer, so they don't get lost in *Messages*, and potentially
> delaying display until a particular action is complete, and the user has
> a chance to see them.

My worry is that we're annoying users with warnings that aren't interesting.

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

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Mon, 25 Oct 2021 11:28:35 -0700

On 10/24/21 20:37 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> - Calls `ding'. This function returns nil on my system, dunno if it does
>>   anything on other systems.
>
> (ding) gives a beep and/or flashes the "visual bell", but many people
> has switched off both -- so you get neither.
>
>> That means there are only
>> three places where the `message' isn't immediately swallowed by whatever
>> comes next (and there's almost always another message coming next),
>> which really means there are only three places where `gnus-error' does
>> anything different from `gnus-message'.
>
> Well, it depends on how you've configured your messaging level...

But both `gnus-error' and `gnus-message' consult the same verbosity
option, so they're not really much different.

>> I think the main concerns here are making sure the user actually sees
>> important messages, through a combination of splitting them off into
>> their own buffer, so they don't get lost in *Messages*, and potentially
>> delaying display until a particular action is complete, and the user has
>> a chance to see them.
>
> My worry is that we're annoying users with warnings that aren't
> interesting.

I haven't changed how `gnus-verbose' works, so that filter does the same
thing it always has. The only real difference is that messages/errors go
into a dedicated buffer, and the user has the option to keep the buffer
hidden (the default), pop it up with a command, or fit it into their
existing Gnus window configuration however they like.

For instance, my *Group* configuration contains nothing but the *Group*
buffer: the right two-thirds of the frame are whitespace. I'd probably
make the *Gnus Log* buffer always visible there, and always hide it
otherwise.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#51335: 29.0.50;
 Use warnings facility for reporting Gnus errors
Date: Mon, 25 Oct 2021 11:33:22 -0700

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> On 10/24/21 20:37 PM, Lars Ingebrigtsen wrote:
>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>
>>> - Calls `ding'. This function returns nil on my system, dunno if it does
>>>   anything on other systems.
>>
>> (ding) gives a beep and/or flashes the "visual bell", but many people
>> has switched off both -- so you get neither.
>>
>>> That means there are only
>>> three places where the `message' isn't immediately swallowed by whatever
>>> comes next (and there's almost always another message coming next),
>>> which really means there are only three places where `gnus-error' does
>>> anything different from `gnus-message'.
>>
>> Well, it depends on how you've configured your messaging level...
>
> But both `gnus-error' and `gnus-message' consult the same verbosity
> option, so they're not really much different.

Though to be clear I'm not advocating getting rid of either of these
now, nothing that drastic. I'd like to put the basics in place, get some
feedback from users, and see what makes sense.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Wed, 27 Oct 2021 15:01:39 +0200

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I haven't changed how `gnus-verbose' works, so that filter does the same
> thing it always has. The only real difference is that messages/errors go
> into a dedicated buffer, and the user has the option to keep the buffer
> hidden (the default), pop it up with a command, or fit it into their
> existing Gnus window configuration however they like.

Sounds good.

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

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#51335: 29.0.50;
 Use warnings facility for reporting Gnus errors
Date: Fri, 05 Nov 2021 17:03:46 -0700

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I haven't changed how `gnus-verbose' works, so that filter does the same
>> thing it always has. The only real difference is that messages/errors go
>> into a dedicated buffer, and the user has the option to keep the buffer
>> hidden (the default), pop it up with a command, or fit it into their
>> existing Gnus window configuration however they like.
>
> Sounds good.

Well, I'm about 75% happy with this. I've attached both the patch I'm
running, and a screenshot of my *Group* configuration with the logging
window visible (I've set `gnus-verbose' to 10). I will suppress the urge
to apologize for my *Group* buffer appearance, I'm in the middle of some
home improvements.

The rightmost blob is the warning category: the "(gnus)". With fuller
adoption it might look like "(gnus nntp)" or "(gnus draft)" or "(gnus
search)", etc. I've made it so `gnus-add-timestamp-to-message' also adds
a timestamp here, though that's not activated in the screenshot.

The main awkwardness come from the fact that warnings.el is kind of set
up for you to incorporate it into other packages, but kind of not. You
can opt to split warnings off into your own buffer, which is great. But
in this case, whether and how warnings are logged and/or displayed
should be mostly controlled by Gnus' existing mechanisms (window
configuration and `gnus-verbose'), and I'm fighting warnings.el on that:

- `warning-suppress-types' should belong solely to the user, but I have
  to push `(gnus)' onto it to shut off automatic display, and move
  display control to Gnus's own knobs.
- There's no :info warning level, and it's unclear if `warning-levels'
  is fair game for packages to fool with. Instructions are given, but
  pushing your own values there will mess up eg `warning-numeric-level',
  and it's hard to know if it's really okay.
- The biggest eyesore in the screenshot is the acres of "disable showing
  disable logging" buttons, which are hardcoded. Again, Gnus has its own
  knobs for these.

Lastly, the messages coming from Gnus are very much set up for regular
message display, in particular the "<message>...done" pattern, which
doesn't work with the warnings setup. If we only use delayed warnings
then each time the warnings are output it runs `delayed-warnings-hook',
which runs `collapse-delayed-warnings', which might be an okay place to
collapse the "...done" lines into one. That hook is supposed to run as
part of the `post-command-hook', though, and it doesn't always run, and
I haven't figured out why yet.

All in all, it nearly works :( Probably there would need to be some
small design changes to warnings.el to make it nice. I still think this
or something like it is worth doing.

Eri

[screenshot.png (image/png, attachment)]

[0001-WIP-on-using-warnings-in-Gnus.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Sat, 06 Nov 2021 19:18:36 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I will suppress the urge
> to apologize for my *Group* buffer appearance, I'm in the middle of some
> home improvements.

😋

> Lastly, the messages coming from Gnus are very much set up for regular
> message display, in particular the "<message>...done" pattern, which
> doesn't work with the warnings setup.

I'm having a bit of a problem with imagining the use case for that bit.
I don't think any users will ever want to look at a log/warning buffer
containing "Sorting threads..." etc -- it looks like a debugging tool
that's should be totally internal and not involve *Warnings* at all.

I don't think any other packages do anything like that with their
logging facilities.

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

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#51335: 29.0.50;
 Use warnings facility for reporting Gnus errors
Date: Sat, 06 Nov 2021 14:17:37 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I will suppress the urge
>> to apologize for my *Group* buffer appearance, I'm in the middle of some
>> home improvements.
>
> 😋
>
>> Lastly, the messages coming from Gnus are very much set up for regular
>> message display, in particular the "<message>...done" pattern, which
>> doesn't work with the warnings setup.
>
> I'm having a bit of a problem with imagining the use case for that bit.
> I don't think any users will ever want to look at a log/warning buffer
> containing "Sorting threads..." etc -- it looks like a debugging tool
> that's should be totally internal and not involve *Warnings* at all.
>
> I don't think any other packages do anything like that with their
> logging facilities.

Well that's mostly because I've turned `gnus-verbose' up to 10, and also
introduced an option `gnus-log-all-messages' which doubles
`gnus-message' output to the logging buffer. That is nil by default, but
I've set it to t here, so this is absolutely as loud as the logging
could possibly be.

If we adopt something like this, I think it would be worth doing a bit
of shuffling regarding which messages are sent through `gnus-error' and
which through `gnus-message'. Probably I'd introduce a `gnus-log'
function, have `gnus-error' call that, and replace some `gnus-message'
calls with `gnus-log'.

Ideally there would be no reason to have the option
`gnus-log-all-messages' at all, and the "Sorting threads..." messages
would only ever be messages.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Sun, 07 Nov 2021 14:40:12 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Well that's mostly because I've turned `gnus-verbose' up to 10, and also
> introduced an option `gnus-log-all-messages' which doubles
> `gnus-message' output to the logging buffer. That is nil by default, but
> I've set it to t here, so this is absolutely as loud as the logging
> could possibly be.

🙀

> If we adopt something like this, I think it would be worth doing a bit
> of shuffling regarding which messages are sent through `gnus-error' and
> which through `gnus-message'. Probably I'd introduce a `gnus-log'
> function, have `gnus-error' call that, and replace some `gnus-message'
> calls with `gnus-log'.
>
> Ideally there would be no reason to have the option
> `gnus-log-all-messages' at all, and the "Sorting threads..." messages
> would only ever be messages.

This reminds me -- I've been wondering whether we should basically drop
all of those ... very verbose messaging thingies and use
`with-delayed-message' instead everywhere.  That is, even with my low
verbosity message, this is what I'm getting when I hit `g':

Checking new news...
nnimap quimby.gnus.org splitting mail...done
nnimap read 0k from quimby.gnus.org
Reading active file from mltest via nnml...
Reading incoming mail from file... [2 times]
nnml: Reading incoming mail (no new mail)...done
Reading active file from mltest via nnml...done
Reading active file from archive via nnfolder...done
Reading active file from archive via nnfolder...done
Reading active file via nndraft...done
Reading active file via nnmbox...done
Checking new news...done

Except the nnimap one, all the rest are instantaneous and just flash
past me.  But we output them because we don't know whether a backend is
slow or not.  With `with-delayed-message' we could avoid all the
"Reading active" messages altogether in a normal setup, but they would
appear if the backend was slow.

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

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Sat, 04 Dec 2021 12:42:18 -0800

[Message part 1 (text/plain, inline)]

Continuing a more piecemeal approach to this, here's a patch to change
the mail source error behavior. I'm floating it for review because it
involves removing a user-facing option. If this goes in, should that
removal be mentioned in NEWS?

[0001-Use-gnus-error-to-report-mail-source-failures.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Sat, 04 Dec 2021 23:13:07 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Continuing a more piecemeal approach to this, here's a patch to change
> the mail source error behavior. I'm floating it for review because it
> involves removing a user-facing option. If this goes in, should that
> removal be mentioned in NEWS?

Looks OK to me.  And, yes, it should be mentioned in NEWS.

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Tue, 13 Sep 2022 16:45:53 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> Continuing a more piecemeal approach to this, here's a patch to change
>> the mail source error behavior. I'm floating it for review because it
>> involves removing a user-facing option. If this goes in, should that
>> removal be mentioned in NEWS?
>
> Looks OK to me.  And, yes, it should be mentioned in NEWS.

This was more than half a year ago -- was there any progress here?

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51335 <at> debbugs.gnu.org
Subject: Re: bug#51335: 29.0.50; Use warnings facility for reporting Gnus
 errors
Date: Mon, 07 Nov 2022 12:53:39 -0800

On 09/13/22 16:45 PM, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>>> Continuing a more piecemeal approach to this, here's a patch to change
>>> the mail source error behavior. I'm floating it for review because it
>>> involves removing a user-facing option. If this goes in, should that
>>> removal be mentioned in NEWS?
>>
>> Looks OK to me.  And, yes, it should be mentioned in NEWS.
>
> This was more than half a year ago -- was there any progress here?

Gah... how did this get bogged down? I think I was originally trying to
abuse warnings.el as a general logging library, and eventually realized
that that simply wasn't going to work, and that sort of took the wind
out of my sails. But the patch here is probably a fine idea no matter
what.

I know you had more general concerns about the verbosity of Gnus'
message output, and that should still be addressed at some point, but my
head is very much out of this particular problem space. I guess I'd like
to apply this patch and close this bug, and come back to the problem
later, with a different solution.

WDYT?

Eric

Previous Next

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