Re: Gnus slow with IMAP when changing ISP's

Re: Gnus slow with IMAP when changing ISP's

[Ted Zlatanov]

On Mon, 16 Nov 2009 21:13:13 +0100 Damian <damian.only@gmail.com> wrote: 

D> I use gnus from work and from home. I have a different ISP in each
D> place. When I start gnus from one of those places (say home) I can
D> access my IMAP account almost right away, however, if I go to the
D> other place (my work) checking for new mail takes forever.

D> In any case the situation is the same. Fire up gnus, read mail,
D> suspend laptop, go to the other place, wake up laptop, check mail,
D> wait till hell gets cold.

D> I've tried restarting gnus, but the problem remains. I have to restart
D> the whole emacs in order to get the normal behaviour again.

Try a different IMAP client, e.g. Thunderbird.  Is it slow from the work
location?

Ted

Re: Gnus slow with IMAP when changing ISP's

[Damián]

On Nov 17, 4:40 pm, Ted Zlatanov <t...@lifelogs.com> wrote:
> On Mon, 16 Nov 2009 21:13:13 +0100 Damian <damian.o...@gmail.com> wrote:
>
> D> I use gnus from work and from home. I have a different ISP in each
> D> place. When I start gnus from one of those places (say home) I can
> D> access my IMAP account almost right away, however, if I go to the
> D> other place (my work) checking for new mail takes forever.
>
> D> In any case the situation is the same. Fire up gnus, read mail,
> D> suspend laptop, go to the other place, wake up laptop, check mail,
> D> wait till hell gets cold.
>
> D> I've tried restarting gnus, but the problem remains. I have to restart
> D> the whole emacs in order to get the normal behaviour again.
>
> Try a different IMAP client, e.g. Thunderbird.  Is it slow from the work
> location?
Actually, if I restart the whole emacs (restarting gnus won't help)
then everything is just fine. So I think it is an emacs related
problem.

Re: Gnus slow with IMAP when changing ISP's

[Nevo]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

2009/11/19 Damián <damian.only@gmail.com>

> On Nov 17, 4:40 pm, Ted Zlatanov <t...@lifelogs.com> wrote:
> > On Mon, 16 Nov 2009 21:13:13 +0100 Damian <damian.o...@gmail.com> wrote:
> >
> > D> I use gnus from work and from home. I have a different ISP in each
> > D> place. When I start gnus from one of those places (say home) I can
> > D> access my IMAP account almost right away, however, if I go to the
> > D> other place (my work) checking for new mail takes forever.
> >
> > D> In any case the situation is the same. Fire up gnus, read mail,
> > D> suspend laptop, go to the other place, wake up laptop, check mail,
> > D> wait till hell gets cold.
> >
> > D> I've tried restarting gnus, but the problem remains. I have to restart
> > D> the whole emacs in order to get the normal behaviour again.
> >
> > Try a different IMAP client, e.g. Thunderbird.  Is it slow from the work
> > location?
> Actually, if I restart the whole emacs (restarting gnus won't help)
> then everything is just fine. So I think it is an emacs related
> problem.
>

I also suffered from this occasionally (not constant) for both gmail and our
private imap server ,it just hang everything sometime when I tried to check
emails (M-g) until I killed the whole emacs, just exactly the same with what
you've told here.  I've once checked the both GNUs log and emacs log, not
finding anything (maybe I missed something else) . And trying to use
"gnutls" tool to connect with imap server, it just returned immediately.  I
believe "Thunderbird" is okay , though most of the time I'm using GNUS.

[-- Attachment #2: Type: text/html, Size: 2142 bytes --]

Re: Gnus slow with IMAP when changing ISP's

[Damian]

>> Actually, if I restart the whole emacs (restarting gnus won't help)
>> then everything is just fine. So I think it is an emacs related
>> problem.
>
> I also suffered from this occasionally (not constant) for both gmail and our
> private imap server ,it just hang everything sometime when I tried to check
> emails (M-g) until I killed the whole emacs, just exactly the same with what
> you've told here.  I've once checked the both GNUs log and emacs log, not
> finding anything (maybe I missed something else) . And trying to use
> "gnutls" tool to connect with imap server, it just returned immediately.  I
> believe "Thunderbird" is okay , though most of the time I'm using GNUS.
>
So could you solve the problm by using gnutls?

Did you only changed (nnimap-stream ssl) by (nnimap-stream tls), or
did you perform any additional tweaks?

Thanks,
Damian.

Re: Gnus slow with IMAP when changing ISP's

[Nevo]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

2009/11/19 Damian <damian.only@gmail.com>

> >> Actually, if I restart the whole emacs (restarting gnus won't help)
> >> then everything is just fine. So I think it is an emacs related
> >> problem.
> >
> > I also suffered from this occasionally (not constant) for both gmail and
> our
> > private imap server ,it just hang everything sometime when I tried to
> check
> > emails (M-g) until I killed the whole emacs, just exactly the same with
> what
> > you've told here.  I've once checked the both GNUs log and emacs log, not
> > finding anything (maybe I missed something else) . And trying to use
> > "gnutls" tool to connect with imap server, it just returned immediately.
>  I
> > believe "Thunderbird" is okay , though most of the time I'm using GNUS.
> >
> So could you solve the problm by using gnutls?
>
> Did you only changed (nnimap-stream ssl) by (nnimap-stream tls), or
> did you perform any additional tweaks?
>

No, I didnot solve this problem ,as I mentioned, it's not so constant . I
only did some test by using "gnutls" to see if it's from server issue. You
may wait to see anyone else having this constantly ,then we could have
chance to figure it out.

>
> Thanks,
> Damian.
>

[-- Attachment #2: Type: text/html, Size: 1746 bytes --]

Re: Gnus slow with IMAP when changing ISP's

[Damian]

On Thu, Nov 19, 2009 at 8:36 AM, Nevo <sakur.deagod@gmail.com> wrote:
>
>
> 2009/11/19 Damian <damian.only@gmail.com>
>>
>> >> Actually, if I restart the whole emacs (restarting gnus won't help)
>> >> then everything is just fine. So I think it is an emacs related
>> >> problem.
>> >
>> > I also suffered from this occasionally (not constant) for both gmail and
>> > our
>> > private imap server ,it just hang everything sometime when I tried to
>> > check
>> > emails (M-g) until I killed the whole emacs, just exactly the same with
>> > what
>> > you've told here.  I've once checked the both GNUs log and emacs log,
>> > not
>> > finding anything (maybe I missed something else) . And trying to use
>> > "gnutls" tool to connect with imap server, it just returned immediately.
>> >  I
>> > believe "Thunderbird" is okay , though most of the time I'm using GNUS.
>> >
>> So could you solve the problm by using gnutls?
>>
>> Did you only changed (nnimap-stream ssl) by (nnimap-stream tls), or
>> did you perform any additional tweaks?
>
> No, I didnot solve this problem ,as I mentioned, it's not so constant . I
> only did some test by using "gnutls" to see if it's from server issue. You
> may wait to see anyone else having this constantly ,then we could have
> chance to figure it out.
I'm having it almost constantly. I just arrived to work, tried to
check for new mail, and I only got a nice clock instead of the mouse
pointer, and that's it. So I don't know what could this be. If I
restart emacs checking for new mail will be almost instantaneous.

Re: Gnus slow with IMAP when changing ISP's

[Nevo]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

2009/11/19 Damian <damian.only@gmail.com>

> On Thu, Nov 19, 2009 at 8:36 AM, Nevo <sakur.deagod@gmail.com> wrote:
> >
> >
> > 2009/11/19 Damian <damian.only@gmail.com>
> >>
> >> >> Actually, if I restart the whole emacs (restarting gnus won't help)
> >> >> then everything is just fine. So I think it is an emacs related
> >> >> problem.
> >> >
> >> > I also suffered from this occasionally (not constant) for both gmail
> and
> >> > our
> >> > private imap server ,it just hang everything sometime when I tried to
> >> > check
> >> > emails (M-g) until I killed the whole emacs, just exactly the same
> with
> >> > what
> >> > you've told here.  I've once checked the both GNUs log and emacs log,
> >> > not
> >> > finding anything (maybe I missed something else) . And trying to use
> >> > "gnutls" tool to connect with imap server, it just returned
> immediately.
> >> >  I
> >> > believe "Thunderbird" is okay , though most of the time I'm using
> GNUS.
> >> >
> >> So could you solve the problm by using gnutls?
> >>
> >> Did you only changed (nnimap-stream ssl) by (nnimap-stream tls), or
> >> did you perform any additional tweaks?
> >
> > No, I didnot solve this problem ,as I mentioned, it's not so constant . I
> > only did some test by using "gnutls" to see if it's from server issue.
> You
> > may wait to see anyone else having this constantly ,then we could have
> > chance to figure it out.
> I'm having it almost constantly. I just arrived to work, tried to
> check for new mail, and I only got a nice clock instead of the mouse
> pointer, and that's it. So I don't know what could this be. If I
> restart emacs checking for new mail will be almost instantaneous.
>

 You may try other email account to see if this problem is persistent.
 Otherwise , you have to find out where Emacs/GNUS is blocked  ,by some
external tools ,such as GDB or elisp debugger ....Sorry, not able to help
you here :)

Nevo

[-- Attachment #2: Type: text/html, Size: 2722 bytes --]

Re: Gnus slow with IMAP when changing ISP's

[Damian]

>> I'm having it almost constantly. I just arrived to work, tried to
>> check for new mail, and I only got a nice clock instead of the mouse
>> pointer, and that's it. So I don't know what could this be. If I
>> restart emacs checking for new mail will be almost instantaneous.
>
>  You may try other email account to see if this problem is persistent.
>  Otherwise , you have to find out where Emacs/GNUS is blocked  ,by some
> external tools ,such as GDB or elisp debugger ....Sorry, not able to help
> you here :)
No probs. I'm also wondering whether emacs is an appropriate tool for
reading/writing emails. But since I don't want to manipulate text
otherwise, I'll try to make this work.

Re: Gnus slow with IMAP when changing ISP's

[Nevo]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

2009/11/19 Damian <damian.only@gmail.com>

> >> I'm having it almost constantly. I just arrived to work, tried to
> >> check for new mail, and I only got a nice clock instead of the mouse
> >> pointer, and that's it. So I don't know what could this be. If I
> >> restart emacs checking for new mail will be almost instantaneous.
> >
> >  You may try other email account to see if this problem is persistent.
> >  Otherwise , you have to find out where Emacs/GNUS is blocked  ,by some
> > external tools ,such as GDB or elisp debugger ....Sorry, not able to help
> > you here :)
> No probs. I'm also wondering whether emacs is an appropriate tool for
> reading/writing emails. But since I don't want to manipulate text
> otherwise, I'll try to make this work.
>

:) . good luck !

[-- Attachment #2: Type: text/html, Size: 1159 bytes --]

Re: Gnus slow with IMAP when changing ISP's

[Damian]

>> No probs. I'm also wondering whether emacs is an appropriate tool for
>> reading/writing emails. But since I don't want to manipulate text
>> otherwise, I'll try to make this work.
>
> :) . good luck !
In the meantime I've found a workaround. Apparently it is a problem
with gnutls. If I kill the process:
    killall gnutls-cli

and check the mails again, then it works fine, without restarting
emacs (hooray!). Sadly I don't have the time (and maybe not the brain)
to hack into gnus to see if this can be solved more elegantly.

But after all we live in an imperfect world, don't we?

Re: Gnus slow with IMAP when changing ISP's

[Damian]

Oh, btw, the problem takes place after returning from a suspend, not
only when changing of ISP's. I discovered that today.

Re: Gnus slow with IMAP when changing ISP's

[Nevo]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

2009/11/20 Damian <damian.only@gmail.com>

> >> No probs. I'm also wondering whether emacs is an appropriate tool for
> >> reading/writing emails. But since I don't want to manipulate text
> >> otherwise, I'll try to make this work.
> >
> > :) . good luck !
> In the meantime I've found a workaround. Apparently it is a problem
> with gnutls. If I kill the process:
>    killall gnutls-cli
>
> and check the mails again, then it works fine, without restarting
> emacs (hooray!). Sadly I don't have the time (and maybe not the brain)
> to hack into gnus to see if this can be solved more elegantly.
>
> But after all we live in an imperfect world, don't we?
>

 Aha. that's surprising.  But using "gnutls-cli" alone doesn't give similar
problem.Apparently, we'r not the only victims, and what Stefan suggested
sounds reasonable : "In any case what I see happen is that the
underlying connection is stuck and doesn't timeout and Gnus's imap backend
doesn't have its own timeout to make up for it."

[-- Attachment #2: Type: text/html, Size: 1773 bytes --]

Re: Gnus slow with IMAP when changing ISP's

[Damian]

>> In the meantime I've found a workaround. Apparently it is a problem
>> with gnutls. If I kill the process:
>>    killall gnutls-cli
>>
>> and check the mails again, then it works fine, without restarting
>> emacs (hooray!). Sadly I don't have the time (and maybe not the brain)
>> to hack into gnus to see if this can be solved more elegantly.
>>
>> But after all we live in an imperfect world, don't we?
>
>  Aha. that's surprising.  But using "gnutls-cli" alone doesn't give similar
> problem.Apparently, we'r not the only victims, and what Stefan suggested
> sounds reasonable : "In any case what I see happen is that the
> underlying connection is stuck and doesn't timeout and Gnus's imap backend
> doesn't have its own timeout to make up for it."
>
Do you think it is time for a bug report?

Re: Gnus slow with IMAP when changing ISP's

[Nevo]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Damian wrote:
>>> In the meantime I've found a workaround. Apparently it is a problem
>>> with gnutls. If I kill the process:
>>>    killall gnutls-cli
>>>
>>> and check the mails again, then it works fine, without restarting
>>> emacs (hooray!). Sadly I don't have the time (and maybe not the brain)
>>> to hack into gnus to see if this can be solved more elegantly.
>>>
>>> But after all we live in an imperfect world, don't we?
>>>       
>>  Aha. that's surprising.  But using "gnutls-cli" alone doesn't give similar
>> problem.Apparently, we'r not the only victims, and what Stefan suggested
>> sounds reasonable : "In any case what I see happen is that the
>> underlying connection is stuck and doesn't timeout and Gnus's imap backend
>> doesn't have its own timeout to make up for it."
>>
>>     
> Do you think it is time for a bug report?
>   
I think fire a bug doesn't hurt , at least three of us encounter the 
same problem.


[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

Re: Gnus slow with IMAP when changing ISP's

[Paul R]

Nevo> I think fire a bug doesn't hurt , at least three of us encounter
Nevo> the same problem.

You can count me as well, and count me twice rather than once, because
this bug bites me at least twice a day, and has done so for a year at
least. I just stumbled upon this thread while looking for an alternative
mail client that would let me read my mail after suspend. Yes, I was
about to quit gnus because that was really too much trouble.

Stefan, I read your patch, thank you for trying to make imap.el more
robust about network surprises.

To answer a previous question, I was not able to reproduce this bug with
any other mail client, and can reproduce on demand with gnus.

-- 
  Paul

Re: Gnus slow with IMAP when changing ISP's

[Ted Zlatanov]

On Fri, 27 Nov 2009 11:31:28 +0100 Paul R <paul.r.ml@gmail.com> wrote: 

Nevo> I think fire a bug doesn't hurt , at least three of us encounter
Nevo> the same problem.

PR> You can count me as well, and count me twice rather than once, because
PR> this bug bites me at least twice a day, and has done so for a year at
PR> least. I just stumbled upon this thread while looking for an alternative
PR> mail client that would let me read my mail after suspend. Yes, I was
PR> about to quit gnus because that was really too much trouble.

PR> Stefan, I read your patch, thank you for trying to make imap.el more
PR> robust about network surprises.

PR> To answer a previous question, I was not able to reproduce this bug with
PR> any other mail client, and can reproduce on demand with gnus.

I put up a request in the emacs-devel list to implement core Emacs
support for TLS.  Emacs itself would be in control of the TLS
connection instead of calling an external process.  I think recovering
from a suspend would be easier then.

Ted

Re: Gnus slow with IMAP when changing ISP's

[Stefan Monnier]

> I use gnus from work and from home. I have a different ISP in each
> place. When I start gnus from one of those places (say home) I can
> access my IMAP account almost right away, however, if I go to the
> other place (my work) checking for new mail takes forever.

By "forever" do you mean that it is slow, or that it really literally
never terminates (i.e. it doesn't work at all)?

I see a similar problem, but in my case it's not just slow, Gnus just
sits there and never terminates.  It looks like the problem has to with
NAT and/or with going from one private subnet to another and/or changing
IP address.  In any case what I see happen is that the underlying
connection is stuck and doesn't timeout and Gnus's imap backend doesn't
have its own timeout to make up for it.

For what it's worth, I've been using the patch below, so that I just hit
C-g when the connection is stuck, and then retry the command which causes
the connection to be re-created from scratch and everything works
fine again.


        Stefan


--- imap.el.~1.21.~	2009-09-28 09:00:51.000000000 -0400
+++ imap.el	2009-11-19 11:28:18.000000000 -0500
@@ -1313,7 +1313,8 @@
     imap-namespace))
 
 (defun imap-send-command-wait (command &optional buffer)
-  (imap-wait-for-tag (imap-send-command command buffer) buffer))
+  (with-local-quit            ; See backtrace in imap-accept-process-output.
+    (imap-wait-for-tag (imap-send-command command buffer) buffer)))
 
 (defun imap-logout (&optional buffer)
   (or buffer (setq buffer (current-buffer)))
@@ -2029,6 +2030,61 @@
 	  (imap-send-command-1 cmdstr))
       tag)))
 
+(defun imap-accept-process-output (proc &rest args)
+  ;; FIXME: This is sometimes called with quit inhibited:
+  ;; Tried to fix it with a `with-local-quit' in imap-send-command-wait.
+  ;; Debugger entered--Lisp error: (error "Blocking call to accept-process-output with quit inhibited!!")
+  ;;   accept-process-output(#<process imap> 0 100 nil)
+  ;;   apply(accept-process-output #<process imap> (0 100))
+  ;;   byte-code("\302\303\b	#\207" [proc args apply accept-process-output] 4)
+  ;;   imap-accept-process-output(#<process imap> 0 100)
+  ;;   imap-wait-for-tag(1937 nil)
+  ;;   imap-send-command-wait("SELECT \"inbox\"")
+  ;;   imap-mailbox-select-1("inbox" nil)
+  ;;   imap-mailbox-select("inbox")
+  ;;   nnimap-possibly-change-group("inbox" "diro")
+  ;;   nnimap-request-article-part(36260 "BODY.PEEK[]" BODYDETAIL "inbox" "diro" nil detail)
+  ;;   nnimap-request-article(36260 "inbox" "diro" nil)
+  ;;   gnus-request-article(36260 "nnimap+diro:inbox")
+  ;;   gnus-async-prefetch-article("nnimap+diro:inbox" t #<buffer *Summary nnimap+diro:inbox*> t)
+  ;;   gnus-async-article-callback(t "nnimap+diro:inbox" 36261 #<marker at 12447484 in  *Async Prefetch Article*> #<buffer *Summary nnimap+diro:inbox*> t)
+  ;;   (lambda (arg) (gnus-async-article-callback arg "nnimap+diro:inbox" 36261 #<marker at 12447484 in  *Async Prefetch Article*> #<buffer *Summary nnimap+diro:inbox*> t))(t)
+  ;;   nnimap-callback(36261 (lambda (arg) (gnus-async-article-callback arg "nnimap+diro:inbox" 36261 #<marker at 12447484 in  *Async Prefetch Article*> #<buffer *Summary nnimap+diro:inbox*> t)) #<buffer  *Async Prefetch Article*>)
+  ;;   (lambda nil (nnimap-callback 36261 (lambda ... ...) #<buffer  *Async Prefetch Article*>))()
+  ;;   run-hooks(imap-fetch-data-hook)
+  ;;   imap-parse-fetch(6731)
+  ;;   imap-parse-response()
+  ;;   imap-arrival-filter(#<process imap> "evaluated the resulting lisp. The lisp looks like this:\r\n\r\n(fset 'findwordfile\r\n   (lambda (&optional arg) \"Keyboard macro.\" (interactive \"p\")\r\n(kmacro-exec-ring-item (quote (\"=13file\" 0 \"%d\")) arg)))\r\n\r\nWhen trying to use the macro, I get this in my minibuffer:\r\n\r\nfindwordfile: Symbol's function definition is void: kmacro-exec-ring-item\r\n\r\nIf I put (require 'kmacro) at the beginning of my file containing\r\nmacros it works.\r\n\r\nIs there a missing autoload before this line?\r\n(defun kmacro-exec-ring-item (item arg)\r\n\r\nThanks for your work.\r\n\r\n/Mats\r\n\r\nIf Emacs crashed, and you have the Emacs process in the gdb debugger,\r\nplease include the output from the following gdb commands:\r\n    `bt full' and `xbacktrace'.\r\nIf you would like to further debug the crash, please read the file\r\nc:/ProgramFiles/emacs-22.2/etc/DEBUG for instructions.\r\n\r\n\r\nIn GNU Emacs 22.2.1 (i386-mingw-nt5.0.2195)\r\n of 2008-03-26 on RELEASE\r\nWindowing system distributor `Microsoft Corp.', version 5.0.2195\r\nconfigured using `configure --with-gcc (3.4)'\r\n\r\nImportant settings:\r\n  value of $LC_ALL: nil\r\n  value of $LC_COLLATE: nil\r\n  value of $LC_CTYPE: nil\r\n  value of $LC_MESSAGES: nil\r\n  value of $LC_MONETARY: nil\r\n  value of $LC_NUMERIC: nil\r\n  value of $LC_TIME: nil\r\n  value of $LANG: SVE\r\n  locale-coding-system: cp1252\r\n  default-enable-multibyte-characters: t\r\n\r\nMajor mode: Emacs-Lisp\r\n\r\nMinor modes in effect:\r\n  encoded-kbd-mode: t\r\n  tooltip-mode: t\r\n  tool-bar-mode: t\r\n  mouse-wheel-mode: t\r\n  menu-bar-mode: t\r\n  file-name-shadow-mode: t\r\n  global-font-lock-mode: t\r\n  font-lock-mode: t\r\n  blink-cursor-mode: t\r\n  unify-8859-on-encoding-mode: t\r\n  utf-translate-cjk-mode: t\r\n  auto-compression-mode: t\r\n  line-number-mode: t\r\n\r\nRecent input:\r\nC-x C-f C-a C-k c : / t e m p / f w f . e l <return>\r\nM-> C-x C-e M-< M-x f i n d w <tab> <return> M-x e m\r\n<backspace> <backspace> r e p o r t SPC e m a <tab>\r\n<return>\r\n\r\nRecent messages:\r\nLoading encoded-kb...done\r\nFor information about GNU Emacs and the GNU system, type C-h C-a.\r\nfwf.el has auto save data; consider M-x recover-this-file\r\nMark set\r\n(lambda (&optional arg) \"Keyboard macro.\" (interactive \"p\")\r\n(kmacro-exec-ring-item (quote (\"=13file\" 0 \"%d\")) arg))\r\nMark set\r\nfindwordfile: Symbol's function definition is void: kmacro-exec-ring-item\r\nLoading emacsbug...\r\nLoading regexp-opt...done\r\nLoading emacsbug...done\r\n\r\n\r\n\r\n\r\n------------=_1217977809-519-0\r\nContent-Type: message/rfc822\r\nContent-Disposition: inline\r\nContent-Transfer-Encoding: 7bit\r\n\r\nX-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02\r\n	(2007-08-08) on rzlab.ucr.edu\r\nX-Spam-Level: \r\nX-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,BAYES_00 autolearn=ham\r\n	version=3.2.3-bugs.debian.org_2005_01_02\r\nReceived: (at 331-done) by emacsbugs.donarmstrong.com; 5 Aug 2008 23:00:06 +0000\r\nReceived: from cyd (CYD.MIT.EDU [18.115.2.24])\r\n	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m75N02Ac029108\r\n	for <331-done@emacsbugs.donarmstrong.com>; Tue, 5 Aug 2008 16:00:03 -0700\r\nReceived: by cyd (Postfix, from userid 1000)\r\n	id 027C957E338; Tue,  5 Aug 2008 19:00:30 -0400 (EDT)\r\nFrom: Chong Yidong <cyd@stupidchicken.com>\r\nTo: \"Matzi Kratzi\" <matzikratzi@gmail.com>\r\nCc: 331-done@emacsbugs.donarmstrong.com\r\nSubject: Re: Bug in kmacro.el?\r\nDate: Tue, 05 Aug 2008 19:00:29 -0400\r\nMessage-ID: <87hc9zxe2a.fsf@stupidchicken.com>\r\nMIME-Version: 1.0\r\nContent-Type: text/plain; charset=us-ascii\r\n\r\nThanks.  I've checked in a fix (autoloading kmacro-exec-ring-item, as\r\nyou suggested).\r\n\r\n\r\n------------=_1217977809-519-0--\r\n\r\n)\r\n1935 OK UID FETCH completed\r\n")
+  ;;   accept-process-output(#<process imap> 0 100 nil)
+  ;;   apply(accept-process-output #<process imap> (0 100))
+  ;;   byte-code("\302\303\b	#\207" [proc args apply accept-process-output] 4)
+  ;;   imap-accept-process-output(#<process imap> 0 100)
+  ;;   imap-wait-for-tag(1936 nil)
+  ;;   imap-send-command-wait("EXAMINE \"diro\"")
+  ;;   imap-mailbox-select-1("diro" examine)
+  ;;   imap-mailbox-examine-1("diro")
+  ;;   imap-message-copyuid-1("diro")
+  ;;   imap-message-copy("36250" "diro" dontcreate nil " *nnimap* diro")
+  ;;   nnimap-request-accept-article("diro" "diro" t)
+  ;;   gnus-request-accept-article("nnimap+diro:diro" nil t t)
+  ;;   eval((gnus-request-accept-article "nnimap+diro:diro" (quote nil) t t))
+  ;;   nnimap-request-move-article(36250 "inbox" "diro" (gnus-request-accept-article "nnimap+diro:diro" (quote nil) t t) t t)
+  ;;   gnus-request-move-article(36250 "nnimap+diro:inbox" "diro" (gnus-request-accept-article "nnimap+diro:diro" (quote nil) t t) t t)
+  ;;   gnus-summary-move-article(nil)
+  ;;   call-interactively(gnus-summary-move-article nil nil)
+  (condition-case nil
+      (apply 'accept-process-output proc args)
+    (quit
+     ;; The IMAP connection can get stuck (not sure why: it may have
+     ;; to do with NAT routers, changing private network, or changing
+     ;; your IP address).
+     ;; Something somewhere should catch this and timeout
+     ;; after a little while, but it seems like currently it doesn't
+     ;; happen, so instead let the user hit C-g to cause the
+     ;; connection to be dropped, so it can be re-opened from scratch.
+     (delete-process proc)
+     (signal 'quit nil))))
+
 (defun imap-wait-for-tag (tag &optional buffer)
   (with-current-buffer (or buffer (current-buffer))
     (let (imap-have-messaged)
@@ -2040,7 +2096,8 @@
 	  (unless (< len 10)
 	    (setq imap-have-messaged t)
 	    (message "imap read: %dk" len))
-	  (accept-process-output imap-process
+	  (imap-accept-process-output
+           imap-process
 				 (truncate imap-read-timeout)
 				 (truncate (* (- imap-read-timeout
 						 (truncate imap-read-timeout))

Gnus slow with IMAP when changing ISP's

[Damian]

Hello,

I use gnus from work and from home. I have a different ISP in each
place. When I start gnus from one of those places (say home) I can
access my IMAP account almost right away, however, if I go to the
other place (my work) checking for new mail takes forever.

In any case the situation is the same. Fire up gnus, read mail,
suspend laptop, go to the other place, wake up laptop, check mail,
wait till hell gets cold.

I've tried restarting gnus, but the problem remains. I have to restart
the whole emacs in order to get the normal behaviour again.

Does anybody have an idea about why this is happening?

Thank you in advance,
Damian.

Gnus slow with IMAP when changing ISP's

[Damián]

Hello,

I use gnus from work and from home. I have a different ISP in each
place. When I start gnus from one of those places (say home) I can
access my IMAP account almost right away, however, if I go to the
other place (my work) checking for new mail takes forever.

In any case the situation is the same. Fire up gnus, read mail,
suspend laptop, go to the other place, wake up laptop, check mail,
wait till hell gets cold.

Does anybody have an idea about why this is happening?

Thank you in advance,
Damian.