Here are a few more ideas I've been kicking around.
User extensibility: so far I have things set up where the external
interfaces and the internal commands will look for certain files and pull
them in; the idea is that the user can place code there which gets compiled
just before normal execution starts. This code can push new commands into
the interface tables, add new config variables, even redefine pieces of the
main code. But after spending a little time reconfiguring Gnus I thought
that it might be nice if the functions came with 'hooks', so that, say,
before the normal welcome routine is run, the code checks for the presence
of a 'welcome_hook' function, runs it, and continues if it returns true.
This would let users add in extra functionality simply, and avoids some of
the 'hack the source' answers that we hate to give.
Command modes: I coded into each command (i.e. unsubscribe, who) the
ability to take a 'mode' to influence its operation. Some examples of
For unsubscribe, modes "allmatching" to remove all matching addresses,
"regexp" to unsubscribe by regexp instead of exact address match, etc.
For lists, cool additional displays like Oliver's stuff that shows
subscribedness (and takes huge amounts of CPU).
For subscribe, "force" to add an address even if it is "equivalent" to
another address already on the list. Think of its application when
mungedomain is in effect. Or perhaps "nowelcome".
Of course the modes would be access-checked separately. I was planning to
implement them (in the email interface) like:
unsubscribe=regexp,allmatching mylist .*aol.com
(Oh, yeah, as I've coded it, subscribe always removes the first match if
there are many. No more freaking out over double-subscribes.)
Comments? More ideas?