Nikolaus Rath writes: > On Jul 20 2015, Eric Abrahamsen wrote: >> Nikolaus Rath writes: >> >>> Hello, >>> >>> The attached revision fixes a small error when parsing the response to >>> the UID MOVE command. Previously, it would fail to find the COPYUID >>> response and fall back to using the message id to determine the UID of >>> the copied message. >> >> I'm running these patches locally, and (I think) seeing more hangs than >> I used to. This only happens on first startup of Gnus. I set >> toggle-debug-on-quit to t, and quit on the next hang -- see the >> traceback below. >> >> This is connecting to a dovecot server running on localhost. The first >> thing this tells me is that the MOVE capability (which dovecot provides) >> isn't getting noticed by Gnus -- as you noted in your previous exchange >> with Lars (was there no resolution to that?). That does need to get >> fixed, otherwise Gnus is missing a lot of added functionality. > > I think I've addressed Lars' comments, so for me the proper resolution > would be for someone to apply the patch :-). How does the attached patch look, instead? It's more code, but the behavior should be cleaner. > >> The other thing is this hang. I'm not immediately inclined to blame Gnus >> for this, but the fact is that this a local connection and there >> shouldn't be anything stalling it. If anyone has any bright ideas... >> >> nnimap-wait-for-response(85) >> nnimap-get-response(85) >> nnimap-command("UID STORE %s +FLAGS.SILENT (\\Deleted)" "") >> nnimap-delete-article(nil t) > > What's the content of the " *nnimap..." buffer at this point? (note the > leading space). It appears I wasn't seeing the problem I thought I was seeing. I traced the login procedure (many times), and it turns out this is `gnus-request-scan' for a server that doesn't support MOVE (outlook.com), so that much is correct. The problem is that the server connection often dies instantly, before the LOGIN is issued, which throws the whole connection process off. At the very least, the wait for response is being called on a dead connection. What's worse is that Gnus seems to be getting confused about which server it's acting on: the traceback above claims to be for the server "PR", but it's actually trying to talk to the server "Outlook". I don't really understand what's happening. Anyway, this isn't a reason to hold up the MOVE patch, so maybe I'll chuck in this CAPABILITY one and then do the MOVE. Sorry this is taking so long. Eric