From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48199 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: Sat, 14 Dec 2002 13:52:22 +0100 Organization: University of Dortmund, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <84lm2skbjt.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> <84of7vxg2t.fsf@lucy.cs.uni-dortmund.de> <87el8qlswk.fsf@gmx.de> <878yyxsp4m.fsf@gmx.de> <873cp4s4m4.fsf@gmx.de> <84smx3o4ck.fsf@lucy.cs.uni-dortmund.de> <87isxydiz0.fsf@gmx.de> <84bs3pubse.fsf@lucy.cs.uni-dortmund.de> <87d6o5et2g.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 1039870564 19723 80.91.224.249 (14 Dec 2002 12:56:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 14 Dec 2002 12:56:04 +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 18NBpp-00057g-00 for ; Sat, 14 Dec 2002 13:56:02 +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 18NBms-0007uz-00; Sat, 14 Dec 2002 06:52:58 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 14 Dec 2002 06:53:46 -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 GAA11313 for ; Sat, 14 Dec 2002 06:53:28 -0600 (CST) Original-Received: (qmail 4586 invoked by alias); 14 Dec 2002 12:52:25 -0000 Original-Received: (qmail 4581 invoked from network); 14 Dec 2002 12:52:24 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by gnus.org with SMTP; 14 Dec 2002 12:52:24 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 18NByX-0000dH-00 for ; Sat, 14 Dec 2002 14:05:01 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 69 Original-NNTP-Posting-Host: pd9e1edc9.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1039871101 2164 217.225.237.201 (14 Dec 2002 13:05:01 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 14 Dec 2002 13:05:01 GMT User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2.93 (i686-pc-linux-gnu) Cancel-Lock: sha1:1amf+7X/KMJ5jmEhRAlDQDxfFSc= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:48199 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48199 Martin Rohde writes: > Sorry, I mixed some things up. > All it saves is the sending of "MyNOOP". It is wrong to speak of > "saving time". Ah, it saves sending that command! Okay, I completely missed that. That's a minor point, but it *is* an advantage. > It just saves the additional code in nntp-open-connection, that's > why I prefer it. But the other version works as well, so if you're > prefering your way, I can send you the working patch, too. No, now I'm convinced that the no-MyNOOP way is better. So I agree with you. > Yes, but i couldn't see a > > (make-local-variable nntp-open-connection-function) > > anywhere. Furthermore, I am not in a special buffer, when I check it > (or am I?), so that's why I asked. Whee. Well, err. The Gnus backend code is pretty convoluted, and I believe any number of wonders that can be done with nnoo. Ah, and nntp-open-connection-function is defvoo'd, not defvar'd. That explains it all. I started to look in defvoo and then in nnoo-define, but I get lost in a twisty maze of little backquotes... Anyhow, I'm almost sure that nnoo has some magic to make the variable local. Anyone? > I thought, it would make the start of gnus a bit faster when you are > using nntp-open-network-stream, because otherwise you would still > have the delay from nntp-accept-response when nntp-send-command is > called for the first time. Hm. This happens if the first command doesn't produce a response, right? Anyhow, it's not so important. Just leave it like that but a comment (connections created with nntp-open-network-stream will never echo; don't bother checking for echoes there) would be nice. >> Secondly, and this is the logic part, the check-for-echo variable >> starts out as nil. I didn't look very closely, but I thought that the >> echo check is skipped when the variable is nil... > > Its global value is nil, but in nntp-make-process-buffer it is > initialized as > > (set (make-local-variable 'nntp-process-delete-echo) t) > > The (defvar nntp-process-delete-echo nil) ist just a dummy > declaration (because of "free variable"-warnings). For it has to be > checked locally in the server-buffers, it doesn't matter, what its > global value is, as you explained before. What do you think about making it (defvar nntp-process-delete-echo t), then then, in nntp-make-process-buffer, to just do (make-local-variable 'nntp-process-delete-echo)? It might make it a little bit clearer what is the default value of the variable, so outsiders have a better chance of understanding the code. Just my two cents. In general, this is good stuff! -- ~/.signature is: umop ap!sdn (Frank Nobis)