emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last change to process.c breaks fetching pop3 mail (gnus/pop3.el)


From: Noah Friedman
Subject: Re: Last change to process.c breaks fetching pop3 mail (gnus/pop3.el)
Date: Thu, 03 Jun 2004 16:26:01 -0700 (PDT)

>To continue on this, what is the proper message to pass to the
>sentinel if the connection was closed by remote peer (or broken).
>
>Current message "exited abnormally with code 256" isn't very good, 
>so perhaps we should change that as well (to what ...?)
>
>However existing code may rely on the current message, so maybe we
>need to leave it as is?

I did a web search just to see if there were any snippets of code which
actually tested for this string.  There weren't a lot, although it's
possible that program sources don't often get indexed.  None of the elisp
files I have archived, including gnu-emacs-sources archives going back
a few years, had any instances of that string literal.  ERC was just about
the only case I could find and that's one of two applications (the other
being zenirc) that prompted me to investigate the sentinel problem in the
first place.

In fact there hasn't been much reason to examine that string because the
process sentinel for network connections has never been called before in
this case; only when the remote end closes the connection would it get
called.  This bug is very old--I can reproduce it in emacs 18.59.

>> But "finished" is the wrong way to decribe delete-process.
>> "deleted" would be more appropriate.
>
>Normally, you would use delete-process to close the connection.
>
>So in that aspect "closed" would be better than "deleted".

"closed" seems ambiguous to me; either side could close a connection.
But only the local side can delete it.  I think changing the process status
signal is the most reliable indicator of who requested the disconnection.
In the meantime the reason string ought to be made more user-friendly
though I don't have any good suggestions.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]