From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53064 Path: main.gmane.org!not-for-mail From: kai.grossjohann@gmx.net (=?iso-8859-1?q?Kai_Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: emacs.gnus Date: Mon, 09 Jun 2003 15:34:02 +0200 Organization: University of Duisburg, Germany Sender: ding-owner@lists.math.uh.edu Message-ID: <84ptln1ik5.fsf@lucy.is.informatik.uni-duisburg.de> References: <84of182xjx.fsf@lucy.is.informatik.uni-duisburg.de> <84znkrk3vr.fsf@lucy.is.informatik.uni-duisburg.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 1055165575 25417 80.91.224.249 (9 Jun 2003 13:32:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2003 13:32:55 +0000 (UTC) Original-X-From: ding-owner+M1608@lists.math.uh.edu Mon Jun 09 15:32:51 2003 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 19PMlW-0006bR-00 for ; Mon, 09 Jun 2003 15:32:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19PMnR-0003ky-00; Mon, 09 Jun 2003 08:34:49 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19PMnI-0003kq-00 for ding@lists.math.uh.edu; Mon, 09 Jun 2003 08:34:40 -0500 Original-Received: (qmail 16788 invoked by alias); 9 Jun 2003 13:34:40 -0000 Original-Received: (qmail 16783 invoked from network); 9 Jun 2003 13:34:39 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by sclp3.sclp.com with SMTP; 9 Jun 2003 13:34:39 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 19PN4p-0006R7-00 for ; Mon, 09 Jun 2003 15:52:47 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 68 Original-NNTP-Posting-Host: pd951f354.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1055166767 24373 217.81.243.84 (9 Jun 2003 13:52:47 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 9 Jun 2003 13:52:47 GMT Mail-Copies-To: never User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:xKQElE09iYlRCRM+jn2LEKI/ejQ= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53064 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53064 Hanak David writes: > On Mon, 09 Jun 2003, Kai Großjohann wrote: > >> The FSF wants to have a copyright assignment for everything that is >> part of Emacs. This way, when somebody violates the GPL, the FSF can >> defend it. I understand that if many people hold the copyright for >> pieces of Emacs, then those people would have to cooperate to defend >> the copyright. > > That sounds perfectly reasonable. But what do I have to do to assign all > copyrights to the FSF? (I've checked the FSF homepage, but haven't found > the HOW, only the WHY.) Sent by private mail. > So, I've recoded it following your guidelines. In fact, I've found a > function called gnus-request-group-articles, which, according to its > docstring, is doing the same as gnus-group-article-list. There was no > equivalent backend function for nnml, so I've done that, but there *was* > one for the nntp backend, which always returned t instead of a list of > article numbers. As far as I could tell, these functions weren't used at > all, so I removed nntp-request-group-articles with another patch. :-{ I think that it is okay for the function to return t. The Gnus manual also has some stuff on how the nnchoke-request-foo functions work. In particular, see the node (gnus)Back End Interface, which says: /---- | There are two groups of interface functions: "required functions", | which must be present, and "optional functions", which Gnus will always | check for presence before attempting to call 'em. | | All these functions are expected to return data in the buffer | `nntp-server-buffer' (` *nntpd*'), which is somewhat unfortunately | named, but we'll have to live with it. When I talk about "resulting | data", I always refer to the data in that buffer. When I talk about | "return value", I talk about the function value returned by the | function call. Functions that fail should return `nil' as the return | value. \---- So t means success, and the "return value" needs to be grabbed from the server buffer. > I could have taken the other road and added a new function (say, > gnus-request-group-artcile-list) to gnus-int.el which seemingly does the > same, but that doesn't sound good either. What do you think? I think the right thing to do is to use the existing function. > *** /usr/share/emacs/site-lisp/gnus/lisp/gnus-sum.el 2003-06-07 19:40:22.000000000 +0200 > --- ./gnus-sum.el 2003-06-09 12:05:22.000000000 +0200 > *************** > *** 5242,5247 **** > --- 5242,5248 ---- > ;; articles in the group, or (if that's nil), the > ;; articles in the cache. > (or > + (gnus-request-group-articles group) Here, you should probably call gnus-request-group-articles and then snarf the data from the nntp-server-buffer. Or, maybe make a convenience function which does this. -- This line is not blank.