From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48127 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: 'g' in the group buffer still very slow Date: Mon, 09 Dec 2002 18:22:34 +0100 Organization: University of Dortmund, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <84of7vxg2t.fsf@lucy.cs.uni-dortmund.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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1039465401 2516 80.91.224.249 (9 Dec 2002 20:23:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Dec 2002 20:23:21 +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 18LUQw-0000eH-00 for ; Mon, 09 Dec 2002 21:23:18 +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 18LUOi-00049p-00; Mon, 09 Dec 2002 14:21:00 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 09 Dec 2002 14:21:50 -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 OAA29295 for ; Mon, 9 Dec 2002 14:21:21 -0600 (CST) Original-Received: (qmail 23567 invoked by alias); 9 Dec 2002 20:20:23 -0000 Original-Received: (qmail 23556 invoked from network); 9 Dec 2002 20:20:22 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by gnus.org with SMTP; 9 Dec 2002 20:20:22 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 18LUYB-00083M-00 for ; Mon, 09 Dec 2002 21:30:47 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 35 Original-NNTP-Posting-Host: p50876cbc.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1039465847 30957 80.135.108.188 (9 Dec 2002 20:30:47 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 9 Dec 2002 20:30:47 GMT User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) Cancel-Lock: sha1:r8Fw3Kr6ozssgTC+IiMAixZOXQY= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:48127 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48127 Martin Rohde writes: > Well, nntp-send-command looks, if there's an echo, and then deletes > it. I don't understand most of the code in nntp-open-connection, so > I don't know if anything of this patch makes sense. And I don't know > how to test it, because i don't know how to force such a local echo. If nobody steps forward to test it (I don't have the time, sadly), then you'll need to find a way to do it yourself. I'm not sure, but you might be successful with using telnet to open a connection. 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.) > What this code does, is to send a "MODE READER" as a No-Op command, > when the connection is established (I think ;), and then it looks, > just like in nntp-send-command, if the command is echoed in the > server-buffer. If so, it deletes it and sets nntp-delete-echo to t > for future reference (I hope). I'm afraid that spot is too early. Some servers might require authentication to log in. Thinking... Hm... Oh! It doesn't matter: if the server requires authentication, then it just sends an error message which is just as good for your purposes as a success message. But "mode reader" is not a no-op, could that be a problem? -- ~/.signature is: umop ap!sdn (Frank Nobis)