From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4450 Path: main.gmane.org!not-for-mail From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) Newsgroups: gmane.emacs.gnus.general Subject: Re: New features + feature freeze? Date: 15 Dec 1995 20:14:39 +0100 Organization: Dept. of Informatics, University of Oslo, Norway Sender: larsi@ifi.uio.no Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145193 29599 80.91.224.250 (20 Oct 2002 20:19:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:19:53 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id LAA02317 for ; Fri, 15 Dec 1995 11:49:01 -0800 Original-Received: from surt.ifi.uio.no (4867@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 20:14:40 +0100 Original-Received: (from larsi@localhost) by surt.ifi.uio.no ; Fri, 15 Dec 1995 20:14:40 +0100 Original-To: ding@ifi.uio.no In-Reply-To: steve@miranova.com's message of 14 Dec 1995 20:02:28 -0800 Original-Lines: 73 Xref: main.gmane.org gmane.emacs.gnus.general:4450 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4450 steve@miranova.com (Steven L. Baur) writes: > Sounds good. At this point I'd rather see all the ``old'' features > work reliably (NOCEM, a port of customize to XEmacs, and Gnus Daemon > come to mind) before adding more stuff. Well -- much of the code I've added to September I haven't even given a cursory run-through. ("Hey, it compiles! Ship it!") NoCeM, group bubbling, Gnus Daemon (and many other things) are among those untested items... For now I find it more exciting to write than to test. There'll be time enough for that when the feature freeze sets in, I think. > Speaking of testing and old features, I've noticed a fair number of > questions regarding usage and problems with Gnus and foreign servers. > Is there anyone who can donate NNTP access to allow Gnus testing on > this? I'd like to test with another NNTP server, but won't have > access to another one until at least mid '96. What I usually do when I want to test two (or more) nntp servers is that I just set up a couple of nntp proxies that all connect to the nntp server I normally use. > Since XEmacs has builtin sound support, it would be kind of nice to > have sound effects. A toilet flushing when deleting articles, the > sound of a flyswatter striking when gnus-summary-mail-nastygram is > sending a message, the sound of letters being dropped into a mail box > when incoming mail arrives, etc. :-) Heh. I kinda like that idea. It's so... *kinky*. An Emacs package that makes noise. > * If we can't have any native Gnus support for color in the *Group* > buffer, how about adding hooks to gnus-group-insert-group-line and > gnus-group-update-group-line so that it can be added without hacking > Gnus source? Well, I think we should add native Gnus highlighting in the group buffer. Perhaps just do it much the same way as highlighting in the summary buffer? The same sort of structures? > + The last time I checked, C-c C-x C-z in a *news* post buffer was an > unwise thing to do `suspend-emacs'? In what way is that unwise? > (Documentation) > * All hook functions need some documentation. At the minimum, there > should be a list of variables that can be safely used in that hook. You mean variables that are dynamically bound when the hook is called? Or global variables that have meaningful values when the hook is called? I don't want to document the dynamical variables since they are likely to change, and listing all global variables for each hook seems a bit excessive. :-) > * All user callable gnus internal functions need to be at least > enumerated, and the calling interface needs to be frozen at some > point too. It's difficult to customize and extend Gnus when it's a > rapidly moving target. All internal functions are user callable, no? I'm slowly adding documentation strings to all Gnus functions. (I'm not doing this systematically -- every time I look & fix a function I just add documentation.) Anyways, I've been keeping the interface to the interactive functions pretty frozen. (I've mostly been adding new optional parameters.) I still think it's a bit too early to promise that I won't change any internal functions. I just don't feel that Gnus is mature enough to say "This is The Way." I make lots of stupid decisions that I later regret... -- Home is where the cat is.