Re: Gnus CVS-Release: Remarks to `nntp-open-connection'

[ShengHuo ZHU <zsh@cs.rochester.edu>]

Christoph Conrad <christoph.conrad@gmx.de> writes:

> I have two remarks to "nntp.el" and the function `nntp-open-connection';
> i have no direct Internet connection (dialup with modem).
> 
> When i startup Gnus when not connected (M-x `gnus-plugged' or
> `gnus-unplugged') or try get new news when plugged and not online
> (`gnus-topic-get-new-news-this-topic') Gnus tries to establish a
> connection and waits for opening it (`nntp-connection-timeout' isn't
> respected). So i C-g the whole thing.

nntp-connection-timeout doesn't work in FSF Emacs, because the alarm
is disabled during connecting.  :-(

,-------- src/process.c
|       /* This turns off all alarm-based interrupts; the
|          bind_polling_period call above doesn't always turn all the
|          short-interval ones off, especially if interrupt_input is
|          set.
| 
|          It'd be nice to be able to control the connect timeout
|          though.  Would non-blocking connect calls be portable?  */
|       turn_on_atimers (0);
|       ret = connect (s, lres->ai_addr, lres->ai_addrlen);
|       xerrno = errno;
|       turn_on_atimers (1);
`--------

> The unbeautiful things are:
> 
> - if there is more than one nntp group in the group buffer, the group
>   buffer isn't shown, cause the whole gnus-(un)plugged quits (cause a
>   quit-signal is re-thrown).

Do you mean it quits gnus-agent-fetch-session (or
gnus-agent-batch-fetch)?  I think a better way is to catch "quit"
signal in g-a-f-s.

> - the nntp buffer isn't closed.

Right, pbuffer should be killed. 

> So i patched `nntp-open-connection':
> 
> (defun nntp-open-connection (buffer)
>   "Open a connection to PORT on ADDRESS delivering output to BUFFER."
> ...
> 	    (quit
> 	     (message "Quit opening connection")
> 	     ;; -cc- (signal 'quit nil)
>          ;; -cc- added
>          (kill-buffer pbuffer)
> 	     nil))))
> 
> I would suggest to kill the buffer (release the resource). If there is a
> more elegant solution to uncommenting the `signal', please let me know.

ShengHuo