Lars Ingebrigtsen <la...@gnus.org> writes: > Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> Looking over the code, I'm inclined to agree with Lars-Johan here: there >> isn't really any need to halt the process, what's important is that the >> user be made aware of the failure. > > I agree. > >> Allow me to re-introduce my suggestion of using warnings! It's looking >> better and better the more I consider it. `delay-warning' is just what >> we want: it puts messages in the hopper, which aren't displayed until >> the current command is completely finished, instead of messages >> clobbering each other and getting buried. It has its own private buffer, >> keeping information separate. There are plenty of user-facing knobs, and >> facilities for hiding or silencing the warnings. > > I'm not sure I want to be popping up a buffer at the user for network > errors and the like -- it's expected that a news reader will have some > network problems, and putting up a buffer about it isn't very helpful.
The pop-up part of it is very easy to fix, it could even be added to the Gnus window configuration stuff so people can have the warnings/reports visible in *Group* but not elsewhere, etc. The real advantages are 1) the warnings go into their own buffer, so they don't get lost in *Messages*, and 2) they can be displayed after the current command returns. Right now, the message about mail source failure message will never be seen by the user. We could easily emulate that behavior, it's just that warnings give it to us for free. There are other approaches, as well. I could also do a limited version of the custom error approach, only for mail sources.
