Re: emacs.gnus

[kai.grossjohann@gmx.net (Kai Großjohann)]

Hanak David <dhanak@inf.bme.hu> 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.