From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48128 Path: main.gmane.org!not-for-mail From: Martin Rohde Newsgroups: gmane.emacs.gnus.general Subject: Re: 'g' in the group buffer still very slow Date: Mon, 09 Dec 2002 23:38:35 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: <87el8qlswk.fsf@gmx.de> References: <87heisn8f4.fsf@sdbk.de> <87d6ocmlux.fsf@sdbk.de> <84adjg8fbd.fsf@lucy.cs.uni-dortmund.de> <87wumk5bmq.fsf@gmx.de> <84k7ijaaz2.fsf@lucy.cs.uni-dortmund.de> <87hedn2su2.fsf@gmx.de> <84of7vxg2t.fsf@lucy.cs.uni-dortmund.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1039473669 7584 80.91.224.249 (9 Dec 2002 22:41:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Dec 2002 22:41:09 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18LWZo-0001w3-00 for ; Mon, 09 Dec 2002 23:40:36 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18LWYT-0004ol-00; Mon, 09 Dec 2002 16:39:13 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 09 Dec 2002 16:40:03 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@[209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id QAA29616 for ; Mon, 9 Dec 2002 16:39:44 -0600 (CST) Original-Received: (qmail 28795 invoked by alias); 9 Dec 2002 22:38:46 -0000 Original-Received: (qmail 28790 invoked from network); 9 Dec 2002 22:38:46 -0000 Original-Received: from mailout03.sul.t-online.com (194.25.134.81) by gnus.org with SMTP; 9 Dec 2002 22:38:46 -0000 Original-Received: from fwd07.sul.t-online.de by mailout03.sul.t-online.com with smtp id 18LWXy-000084-05; Mon, 09 Dec 2002 23:38:42 +0100 Original-Received: from ParadiseCity (0202731138-0001@[217.83.109.151]) by fmrl07.sul.t-online.com with esmtp id 18LWXw-16XqrYC; Mon, 9 Dec 2002 23:38:40 +0100 Original-Received: by ParadiseCity (Postfix, from userid 1000) id 7F46BF52C1; Mon, 9 Dec 2002 23:38:35 +0100 (CET) Original-To: ding@gnus.org In-Reply-To: <84of7vxg2t.fsf@lucy.cs.uni-dortmund.de> (kai.grossjohann@uni-duisburg.de's message of "Mon, 09 Dec 2002 18:22:34 +0100") X-Now-Playing: Metallica - Astronomy User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) X-Sender: 0202731138-0001@t-dialin.net Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:48128 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48128 On Day 51 of The Aftermath 3168, Kai Großjohann wrote: > You could create a new server definition that uses telnet instead of > connecting directly. See the variable nntp-open-connection-function > and the function nntp-open-telnet-stream, referenced from the > variable. Maybe you can twiddle the telnet args such that echoing is > used? You might wish to manually send stuff to the server in the > server buffer (" *server foo *nntpd*" or somesuch, mind the leading > space) using process-send-string. Then you can see whether the > server echoes commands. (I hope that the echo removal isn't done in > a process filter.) Ok, now i used nntp-open-telnet-stream and looked at the server buffer (thanks for the hints). There were several lines like "LIST ACTIVE ", so commands are echoed and the lines are not deleted. With nntp-open-network-stream or with an older version of nntp.el the buffer is "clean". Obviously my patch didn't worked, but now I figured out, that it acted in the wrong buffer. And I found another problem: After the test-command is send, I somehow have to find out, when the response has arrived, so that I can look at the echo then. I thought a (nntp-wait-for "^2.*\n" process buffer [...]) would work, but then the echo is not found for unknown reasons (I have to confess, that I don't really know, what I am doing here, maybe nntp-wait-for is erasing the buffer for some reason...). I just tried it with a (sleep-for 2) right after the nntp-send-string-command to wait until the echo is in the server buffer, just to see if the rest of my code is ok, and it "works" now. (That means, nntp-delete-echo is set properly) Of course, this is too ugly, so I need a reasonable possibility to wait for the response. I thought of a kind of loop, but this wouldn't be that much prettier IMHO. Is there a function i can use for this? > But "mode reader" is not a no-op, could that be a problem? I'm not quite sure. I wanted to send a command, that doesn't have affects on gnus and I read, that "mode reader" often is used as a no-op. Maybe "slave" would be a better idea? (I don't have a clue about nntp :) Thanks for your advise, Martin.