bug#5924: 23.1; accept-process-output switching current-buffer

[Uday S Reddy <u.s.reddy@cs.bham.ac.uk>]

Dear Stefan,

I have now tried this with the Windows build that was published today:
emacs-20100523.  The same problem occurs.  (Of course, there was no
reason to expect that anything would be different.)

Even though I am able to protect the spurious buffer-change inside VM
using my wrapper for accept-process-output, I can't do anything if
some other process is invoked and the VM process interferes with it.
This is now regularly occurring with smtpmail.  In the middle of
smtpmail, the buffer is changing to VM's IMAP process buffer (invoked
for an FCC to an IMAP folder), and smtpmail fails.  Sometimes the smtp
has gone through and sometimes it hasn't.  This is getting to be an
annoyance.

I am repeating my previous message again below, because it got
MIME-encoded in a strange way last time:

----

Here is my current proxy for accept-process-output:

  (defsubst vm-accept-process-output (process)
    "Accept output from PROCESS.  The variable `vm-imap-server-timeout'
  specifies how many seconds to wait before timing out.  If a timeout
  occurs, typically VM cannot proceed."
    ;; protect against possible buffer change due to bug in Emacs
    (let ((buf (current-buffer))
	  (got-output (accept-process-output process vm-imap-server-timeout)))
      (if got-output
	  (when (not (equal (current-buffer) buf))
	    (if (string-lessp "24" emacs-version)
		;; the Emacs bug should have been fixed
		(message 
		 "Emacs process output error: Buffer changed to %s" 
		 (current-buffer)))
	    ;; recover from the bug
	    (set-buffer buf))
	(vm-imap-protocol-error "No response from the IMAP server"))))

and the error came up pretty much the first time I tried it:

  Emacs process output error: Buffer changed to saved IMAP mailhost.c 10:31:09

The current-buffer should have been "IMAP mailhost.c 10:31.40".  But
it switched to the "IMAP mailhost.c 10:31:09" (call it the "old
buffer") because its process sent some output.

I am attaching the contents of the old buffer.  I think the last line
would have been output while the current accept-process-output was
done.  (Note that this line came in a few seconds after the current
process got started.)

-----

starting IMAP session Thu May 20 10:31:09 2010
connecting to mailhost.cs.bham.ac.uk:143
connected for fetch
* OK IMAP4 Ready imap 0001cdf3
VM CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1
VM OK CAPABILITY
VM LOGIN <parameters omitted>
VM OK Logged in.
VM SELECT "INBOX"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft forwarded filed redistributed
! $Forwarded 7350 7354 7391 signed * accept action plagiarism Junk NonJunk !@)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft forwarded filed
redistributed ! $Forwarded 7350 7354 7391 signed * accept action plagiarism
Junk NonJunk !@ \*)] Flags permitted.
* 2648 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1217243146] UIDs valid
* OK [UIDNEXT 26600] Predicted next UID
VM OK [READ-WRITE] Select completed.
VM UID FETCH 26471:26471 (RFC822.SIZE)
* 2594 FETCH (RFC822.SIZE 58175 UID 26471)
VM OK Fetch completed.
VM UID FETCH 26471:26471 (BODY.PEEK[])
* 2594 FETCH (UID 26471 BODY[] {58175}
)
VM OK Fetch completed.
VM NOOP
VM OK NOOP completed.
VM UID FETCH 26582:26582 (RFC822.SIZE)
* 2638 FETCH (RFC822.SIZE 2181 UID 26582)
VM OK Fetch completed.
VM UID FETCH 26582:26582 (BODY.PEEK[])
* 2638 FETCH (UID 26582 BODY[] {2181}
)
VM OK Fetch completed.
VM NOOP
VM OK NOOP completed.
VM UID FETCH 26471:26471 (RFC822.SIZE)
* 2594 FETCH (RFC822.SIZE 58175 UID 26471)
VM OK Fetch completed.
VM UID FETCH 26471:26471 (BODY.PEEK[])
* 2594 FETCH (UID 26471 BODY[] {58175}
)
VM OK Fetch completed.
VM NOOP
VM OK NOOP completed.
VM UID FETCH 26578:26578 (RFC822.SIZE)
* 2635 FETCH (RFC822.SIZE 52388 UID 26578)
VM OK Fetch completed.
VM UID FETCH 26578:26578 (BODY.PEEK[])
* 2635 FETCH (UID 26578 BODY[] {52388}
)
VM OK Fetch completed.
VM LOGOUT
* BYE Logging out
VM OK Logout completed.

Process IMAP<2> connection broken by remote peer
ending IMAP session Thu May 20 10:31:43 2010

---

Cheers,
Uday