From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5723 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Q: Extending nntp (for nndb) Date: 27 Mar 1996 04:49:37 +0000 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146287 1220 80.91.224.250 (20 Oct 2002 20:38:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:38:07 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.3/8.6.9) with SMTP id VAA31285 for ; Tue, 26 Mar 1996 21:37:53 -0800 Original-Received: from hler.ifi.uio.no (4867@hler.ifi.uio.no [129.240.94.23]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 27 Mar 1996 05:49:38 +0100 Original-Received: (from larsi@localhost) by hler.ifi.uio.no ; Wed, 27 Mar 1996 05:49:37 +0100 Original-To: ding@ifi.uio.no Original-Lines: 38 Xref: main.gmane.org gmane.emacs.gnus.general:5723 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5723 Kai Grossjohann writes: > The documentation for, say, nnchoke-request-accept-article, says: > > ,----- > | `(nnchoke-request-accept-article GROUP &optional LAST)' > | This function takes the current buffer and inserts it into > | GROUP. If LAST in `nil', that means that there will be more > | calls to this function in short order. > | > | There should be no data returned. > `----- > > Note the last sentence. By "data", the manual means "data in the nntpd buffer". I forgot to mention the function return value. > Further, when in a function, how do I find out the values of all the > parameters (host, port, whatever), considering that the currenly valid > value may come from a group parameter, may come from the server > definition, or may come from one of the variables which change the > defaults. And this isn't considering the environment variables, even. The `*-open-server' function sets all variables in the backend. So all the other functions can assume that they are working on variables local to the current virtual server. > Maybe this was a completely stupid approach of doing it? Should I've > copied nntp.el then change every occurrence of "nntp" to "nndb", then > change the defaults at will? Yes, probably. nndb and nntp are sufficiently different that there probably should be a new nndb.el file. -- "Yes. The journey through the human heart would have to wait until some other time."