[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51335: 29.0.50; Use warnings facility for reporting Gnus errors
From: |
Eric Abrahamsen |
Subject: |
bug#51335: 29.0.50; Use warnings facility for reporting Gnus errors |
Date: |
Fri, 22 Oct 2021 10:04:39 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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
Description: Text Data
- bug#51335: 29.0.50; Use warnings facility for reporting Gnus errors,
Eric Abrahamsen <=