bug#51335: 29.0.50; Use warnings facility for reporting Gnus errors

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 10/24/21 20:37 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@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.