From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48183 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: Fri, 13 Dec 2002 18:18:15 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: <87d6o5et2g.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> <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> 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 1039800141 2208 80.91.224.249 (13 Dec 2002 17:22:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 13 Dec 2002 17:22: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 18MtVw-0000Yh-00 for ; Fri, 13 Dec 2002 18:22:16 +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 18MtTU-0004Zf-00; Fri, 13 Dec 2002 11:19:44 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 13 Dec 2002 11:20:35 -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 LAA09528 for ; Fri, 13 Dec 2002 11:20:08 -0600 (CST) Original-Received: (qmail 400 invoked by alias); 13 Dec 2002 17:18:28 -0000 Original-Received: (qmail 393 invoked from network); 13 Dec 2002 17:18:28 -0000 Original-Received: from mailout08.sul.t-online.com (194.25.134.20) by gnus.org with SMTP; 13 Dec 2002 17:18:28 -0000 Original-Received: from fwd10.sul.t-online.de by mailout08.sul.t-online.com with smtp id 18MtSD-0003sG-01; Fri, 13 Dec 2002 18:18:25 +0100 Original-Received: from ParadiseCity (0202731138-0001@[217.230.121.83]) by fmrl10.sul.t-online.com with esmtp id 18MtS6-05gnkOC; Fri, 13 Dec 2002 18:18:18 +0100 Original-Received: by ParadiseCity (Postfix, from userid 1000) id 9199AF52BC; Fri, 13 Dec 2002 18:18:15 +0100 (CET) Original-To: ding@gnus.org In-Reply-To: <84bs3pubse.fsf@lucy.cs.uni-dortmund.de> (kai.grossjohann@uni-duisburg.de's message of "Fri, 13 Dec 2002 17:24:49 +0100") X-Now-Playing: Offspring - Self Esteem 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:48183 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48183 On Day 55 of The Aftermath 3168, Kai Großjohann wrote: > Martin Rohde writes: > >> On Day 54 of The Aftermath 3168, Kai Großjohann wrote: >> >>> You can put the definition in the server parameters, like this: >>> >>> (add-to-list 'gnus-secondary-select-methods >>> '(nntp "servername" >>> (nntp-address "host.name.of.server") >>> (nntp-open-connection-function nntp-open-telnet-stream) >>> ...other.nntp-open-telnet.settings...)) >> >> Oops. Sorry, then Kevin was right, nntp-delete-echo has to be >> buffer-local. > > Yes. > >> I fixed the cleaning of the server-buffer after sending "MyNOOP" >> like you suggested and it works, but I like the version of Kevin >> very much. In my opinion it works just as well as testing for an >> echo in nntp-open-connection, but saves code and time. > > Hm? If the code is simpler, I'm all for it, but I don't see what time > it saves. Is it quicker to implement or easier to maintain, or does > it run quicker? Sorry, I mixed some things up. All it saves is the sending of "MyNOOP". It is wrong to speak of "saving time". 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. >> Hm, but it is right to refer to nntp-open-connection-function >> globally, isn't it? It is connection-dependend, too, but I just >> found it as a global variable...(That's why I thought, that it >> would be independent...) > > Code referring to a buffer-local variable looks the same as code > referring to a global variable. See this: > > (defvar x nil) ; declare > (setq x 1) ; global value > ; switch to some buffer foo > (make-local-variable 'x); now it will be local to the foo buffer > x => 1 ; local value same as global initially > (setq x 2) ; set the local value > x => 2 ; local value > ; switch back to previous buffer > x => 1 ; access global value again > > As you can see, the setq looks the same and the access also looks the > same. The only difference is the make-local-variable. 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. >> If so, here is yet another try: > > Looks good to me, even though I'm not so sure about the logic. > > First of all, you still test the connection function, is that still > necessary? If the look-for-echo test works well, it should be okay to > apply it always, making the code (a tiny bit) simpler. 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. > 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. Martin