Re: Better error reporting and stuff on startup

[Richard Riley <rileyrg@googlemail.com>]

Rupert Swarbrick <rswarbrick@gmail.com> writes:

> Tassilo Horn <tassilo@member.fsf.org> writes:
>>> Would it make sense for Gnus to (kind of) collect all the "important"
>>> messages (to be determined somehow), and then display them at the end?
>>> Somehow?
>>
>> That makes sense for any package, but not every package should need to
>> implement something like it.  So it would be cool to extend the
>> `message' mechanism in emacs, so that it allows for different severities
>> (debug, info, warning?) and assign messages to packages, so that I could
>> restrict *Messages* to show only warning messages from Gnus...
>
> Hmm, but how would the user use this? I mean, what presumably happens at
> the moment is that Jo Bloggs types M-x gnus, waits a second (while
> watching flickering stuff at the bottom of the screen) then sees that
> some groups have '*'s rather than numbers. If he[1] knows a reasonable
> amount about emacs then, swearing to himself, he goes to *Messages*. If
> he's lucky, the messages haven't yet scrolled out of the buffer. Next
> time he hits 'g' or types M-x gnus, everything mysteriously works (the
> server or net connection is back up).
>
> Now, how would a proposal to allow the user to filter only warning-level
> messages help Jo?

Assuming the messages contain properties indicating severity and package
its but a hot key away from gnus to  syphon out the relative messages.
>
> I'm not sure whether Lars's idea is perfect, but it seems that whatever
> solution chosen, it should be one that the user doesn't have to
> configure. Especially since Gnus interacts with the outside world via
> the network so is going to be exposed to all sorts of transient faults.

Not all the time no. Often it only deals with local servers : local imap
and possibly a leafnode nntp proxy. In fact I bet gnus is used with
local sources pretty often and other tools do the actual push and pull.