Re: New features + feature freeze?

[larsi@ifi.uio.no (Lars Magne Ingebrigtsen)]

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.