From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32839 Path: main.gmane.org!not-for-mail From: ShengHuo ZHU Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus CVS-Release: Remarks to `nntp-open-connection' Date: 09 Oct 2000 14:49:01 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: <5bitr1q28y.fsf@brandy.cs.rochester.edu> References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035169054 22046 80.91.224.250 (21 Oct 2002 02:57:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:57:34 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35]) by mailhost.sclp.com (Postfix) with ESMTP id CBFE5D051E for ; Mon, 9 Oct 2000 14:54:16 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id NAC11965; Mon, 9 Oct 2000 13:49:31 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 09 Oct 2000 13:48:48 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id NAA14762 for ; Mon, 9 Oct 2000 13:48:38 -0500 (CDT) Original-Received: from gate.cs.rochester.edu (gate.cs.rochester.edu [192.5.53.207]) by mailhost.sclp.com (Postfix) with ESMTP id 55B24D051E for ; Mon, 9 Oct 2000 14:49:03 -0400 (EDT) Original-Received: from brandy.cs.rochester.edu (brandy.cs.rochester.edu [192.5.53.199]) by gate.cs.rochester.edu (8.8.8+Sun/T--) with ESMTP id OAA22205; Mon, 9 Oct 2000 14:49:02 -0400 (EDT) Original-Received: (from zsh@localhost) by brandy.cs.rochester.edu (8.9.1b+Sun/Q++) id OAA15198; Mon, 9 Oct 2000 14:49:02 -0400 (EDT) Original-To: Christoph Conrad X-Attribution: ZSH X-Face: 'IF:e51ib'Qbl^(}l^&4-J`'P!@[4~O|&k#:@Gld#b/]oMq&`&FVY._3+b`mzp~Jeve~/#/ ERD!OTe<86UhyN=l`mrPY)M7_}`Ktt\K+58Z!hu7>qU,i.N7TotU[FYE(f1;}`g2xj!u*l`^&=Q!g{ *q|ddto|nkt"$r,K$[)"|6,elPH= GJ6Q In-Reply-To: Original-Lines: 58 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.4 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:32839 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32839 Christoph Conrad 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