Lars Ingebrigtsen <la...@gnus.org> writes: > Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> I've got my nntp server set in `gnus-select-method', maybe that's why? >> This has annoyed me off and on for years but I've never taken the time >> to look into it. My other servers are all localhost nnimap and I never >> see errors there. I just set debug-on-message appropriately, and will >> figure out exactly where things are going off. > > Tried > > (setq gnus-select-method '(nntp "localhost")) > > and that worked fine, too. There's probably errors that aren't > handled well, but there's infrastructure to collect all the erroring > backends and display the errors at the end. Well, at least there used > to be; haven't actually looked at the code now. :-)
I put plain old calls to `error' inside `nnimap-request-scan', and that also derailed the "g" update process. So whatever handling there once was either is not around this particular piece of code, or else it might have gone away at some point. I had had `nntp-connection-timeout' set to 6, as it hangs indefinitely otherwise. I stuck a call to `error' inside `nntp-report'; so far I can't get an actual backtrace, I guess because there _is_ error handling for nntp. But even there I don't think it's "flow control" handling, it appears to just be error demotion. Are you likely to recall further how this once worked? :) I can start sketching out some custom errors, otherwise. Eric
