-.gnus repository:
-http://superdave.socom.com/gnus/
+;; Also know as the "wish list". Some are done. For the others, no
+;; promise when to be implemented.
-I would like the zombie-page to contain an URL to the source of the
+* Use a new custom type (`define-widget') for posting-style in `gnus-cus.el'
+ (G c) and for `gnus-posting-styles'. Maybe some allowed types are still
+ missing.
+
+* Add proper doc strings to functions and variables explained in the manual
+ (info "(gnus)Gnus Utility Functions")
+
+* Add Message-IDs or URLs refering to relevant discussions on lists and
+ newsgroups.
+
+* Use nicer tool bar icons from GNOME
+
+ Done for Emacs (The GNOME icons won't fit into standard XEmacs icons,
+ IMHO. -- rsteib) in group, summary and message mode.
+
+ Some modes might also deserve improved tool bars:
+
+ - gnus-draft-mode
+
+ - mml-preview buffer:
+
+ . zap most buttons; except print, customize (?) and help
+
+ . "exit" should just kill the buffer
+
+ - gnus-server-mode: Add some commands from the Connections and Server
+ menu.
+
+ - gnus-browse-mode (could borrow some icons from gnus-group-mode)
+
+ (See http://article.gmane.org/gmane.emacs.gnus.general/62147).
+
+* Maybe Gnus should support the LIST SUBSCRIPTIONS, see RFC 2980.
+
+* Merge `message-extra-wide-headers' and ` message-header-synonyms'?
+
+* Maybe texi/emacs-mime.texi could be divided into user-visible stuff and
+ reference manual for the MIME library.
+
+ Related: Bill Wohler's article on mh-e-user.
+ http://thread.gmane.org/29067.1138078896@olgas.newt.com
+
+* Fix `change servers' command, see David Kastrup's message.
+ http://thread.gmane.org/x54qewqxz4.fsf@lola.goethe.zz
+
+* texi/gnus-coding.texi should be fixed.
+
+* gnus-topic-kill-region
+ From Colin Marquardt <colin.marquardt@usa.alcatel.com>
+
+ I noticed that when re-arranging topics, C-k yanks a topic just fine
+ (runs gnus-topic-kill-group).
+
+ However, my habit is to do marking and the yanking the region, so I
+ would run C-w on the marked topic. But C-w runs
+ gnus-group-kill-region and doesn't yank the topic (for groups it
+ works fine).
+
+ So could we have a gnus-topic-kill-region, or a
+ gnus-group-kill-region which handles topics as well?
+
+* Speed up sorting in summary buffer if there is a limit.
+
+ Suggested by Daniel Ortmann <ortmann@isl.net>.
+
+* Investigate the memory usage of Gnus.
+
+ But it does seem strange that Gnus would use some 15meg for this. I
+ think that is worth investigating. I suspect that bugs or bad
+ design are causing waste; they could be in Gnus, or in Emacs. -- RMS
+
+* Google group digest
+
+ The result of Google group search return a thread. Is it a digest
+ format?
+
+* NOV caching.
+
+ Implement NOV caching with Gnus Agent.
+
+* Allow specification of server in Newsgroups header
+
+ [Kai wrote]
+
+ WIBNI I could put `Newsgroups: nntp+quimby:bla' into a message and
+ Gnus would know to post this message on my server `nntp:quimby' into
+ the group bla? I think this would be way cool.
+
+ But Gnus would have to rewrite the Newsgroups header before actually
+ sending the posting.
+
+ Thanks for Micha Wiedenmann for this suggestion.
+
+* Parsing of the common list confirmation requests so that Gnus can
+ prepare the response with a single command. Including LISTSERV
+ periodic ping messages and the like.
+
+* Parsing of the subscription notice to stash away details like what
+ address you're subscribed to the list under (and automatically send
+ mail to the list using that address, when you send mail inside the list
+ group), what address to mail to unsubscribe, and the list info message
+ if available. Hitting the "get FAQ" command inside a mailing list
+ group should display that stashed copy of the info message.
+
+* Some help in coming up with good split rules for mailing lists, as
+ automated as possible. Splitting on To and Cc is almost always not
+ what I want, since it can misfile messages and since if I'm cc'd on
+ list mail I want to get both copies, one in my personal mailbox and one
+ in the list mailbox. I know other people handle it other ways, but I
+ prefer it that way. Accordingly, some way to semi-automatically
+ generate split rules based on Sender, Mailing-List, Return-Path,
+ X-Loop, and all of the other random headers that often work would be
+ very cool.
+
+* Support for zipped folders for all backends this makes sense for.
+ Most likely using jka-compr. (It has been suggested that this do
+ work but I think it should be verified for all backends.)
+
+* Agent (Can someone write some subtopics here? I don't use it myself
+ so I don't know what is lacking.)
+
+* Support for encrypted folders. Even if the mail arrives unencrypted
+ Gnus should be able to encrypt the *folder* for added safety. This
+ should go for both Gnus' own folders and the folders Gnus reads from
+ (e.g. /var/spool/mail/${USER}). All backends this makes sense for.
+
+ [John Wiegley's article <200011030445.VAA08277@localhost.dynodns.net>,
+ posted on gnu.emacs.gnus does this.
+ Also, gnus-article-encrypt `K E' encrypts the article body.]
+
+* Splitting .newsrc.eld so the history is in one file and the
+ configuration is in another. To help those that reads at two
+ locations (e.g. work and home) and want to have the same
+ configuration.
+
+* gnus-uu-decode should complain if one or more parts of a series post
+ (ie, "part N of X") is missing, and optionally tick what parts are
+ there for decoding in a later session.
+
+* Additional article marking, and an ability to affect marks placed
+ during e.g. mail acquisition. I want to be able to notice the
+ subject "fast money" or "web traffic", automatically mark it with a
+ `$', and score it into oblivion. (But I fear that wanting to change
+ marks with mail-source-* and nnmail-* functions will represent a
+ philosophical conflict with the rest of Gnus' management of article
+ marks. mail-source-* and nnmail-* currently hack around with files
+ under ~/Mail and leave traces in ~/Mail/active, but don't affect
+ things stored in .newsrc.eld.)
+
+* A much better interface to nnmail-split-methods. I don't know how
+ I'd like this done, but I know that the current method of manually
+ hacking regexps is pretty untenable for new users. My boss, who is
+ tenured faculty at CMU and CEO & CTO at JPRC, and whose research
+ work has involved Lisp for the last 25 years, is trying to implant
+ himself in a Gnus mail environment, and this is a big sticking point
+ even for him.
+
+* PGP-supported encryption of entire nnml & nnmh groups. There are
+ people with whom I exchange mail routinely who don't send w/PGP, but
+ I'd really rather that the content not be left lying around
+ unencrypted. Hook into article acquisition the way jka-compr
+ supposedly does, to auto-decrypt every message read.
+
+ [See Support for encrypted folders.]
+
+* Baby's First Mail In Gnus. Some set of functions that the
+ new-to-mail-in-Gnus user can invoke which will query the user
+ appropriately for the basic information required to establish mail
+ handling, leaving the appropriate traces in .gnus. Perhaps a
+ customize buffer would be appropriate.
+ - Where does your mail come from?
+ - If some server, what is your POP/IMAP protocol identity?
+ - What is your identity when sending mail, as opposed to posting to
+ Usenet?
+ - Here are some basic concepts of mail groups (list a few:
+ personal mail, company-wide mail, mailing lists, garbage dumps,
+ receptacles for outbound copies of what one sends; which ones do
+ you want to instantiate, and what mail should land in each?
+ [/viz./ problem of nnmail-split-methods interface.]
+
+ [Probably `assistant.el' will provide this. But it's development is
+ stalled.]
+
+* Full integration of nnir into Gnus. Generic hooks for adding new
+ external nnir sources. I use a couple experimental, in-house tools
+ (JPRC is a research lab, occupied with document analysis and machine
+ learning) and adding new search engines to nnir by hacking the main
+ nnir.el module is rather clunky.
+
+* Manual ordering of articles in an nnml folder.
+
+ That is, keystrokes to move articles (or whole threads) up or down
+ in the *Summary* buffer relative to the other articles. The order
+ would be persistent (e.g., across gnus sessions).
+
+ With this ability, an nnml folder would make for a good to-do list.
+
+* Since many uses Gnus to store to do lists I think it is time for an
+ nntodo. (I know Kai already written one, maybe use that for a start?)
+
+* nnsql backend, which would allow messages or folders to be imported
+ in a local (My|Postgre|?)SQL RDBMS.
+
+* "posting profiles" ideally accessible from a popup menu; allowing
+ choice between predefined profiles of
+ from,name,organization,etc. Example: I'm at home, but need to reply
+ to a work mail; i can hit 'R', then use this command to switch to my
+ 'work' profile for purposes of this one reply. (This might already
+ be possible with current Gnus, but I don't think so.)
+
+* Better handling of the mail retrieving / splitting feature:
+ - the variables <backend>-get-new-mail should not exist anymore. Mail
+ retrieving should be a separate matter.
+ - we should be able to split mails to groups AND backends at the same time.
+ - meanwhile, we should still be able to associate certain mail sources with
+ certain backends.
+
+* A better interface to the agent download scoring rules, like the one
+ for the other scoring rules.
+
+* Editing of messages in the agents cache.
+
+* More article marks (like '!' or '?').
+ Maybe user defined marks that can be displayed as any choosen charakter,
+ so one could do things like limiting on, to do whatever one likes with
+ these articles.
+
+* Allow article editing in groups which do not support it, but
+ emulating it via deleting the old article and entering the new one
+ into the group. This would be very useful to support `T ^' (say) in
+ nnimap groups.
+
+* Allow user to specify which kinds of groups should be displayed.
+ For example, I want to display all the groups that are displayed
+ now, plus those which have cached messages in them. (Gnus does
+ display those with ticked messages but not those with
+ cached-but-unticked ones.) This would become even more important
+ when we allow labels.
+
+* Create new data type `article identifier' and use that instead of
+ article numbers. A first implementation could offer something like
+ (num . 4711) but this could be extended. This would be useful for
+ using servers with *really* large numbers -- there we could have a
+ bignum type. It might also be useful for the nnweb and nnultimate
+ thingies where article identifiers are not really numbers.
+
+* Allow use of digests to keep related articles. Normally, you use
+ groups to group together articles which are thematically related.
+ But sometimes, you have so many themes that this becomes
+ impractical. WIBNI I could have digests in a group, and there was a
+ way to add a new article to one of the digests in that group?
+
+ Or maybe what I really want is a way to tell Gnus that a specific
+ thread should always be hidden (as in `T h') by default, while most
+ other threads are not hidden by default. Hm.
+
+* New backend nnbabylfolder. There is also nnbabyl which is like
+ nnmbox but uses babyl format, but there is no babyl format
+ equivalent of nnfolder.
+
+* Make movement commands in summary buffer independent of `move after
+ mark' behavior when marking articles. Currently, if you don't want
+ `E' to move to the next unread article, you have to set
+ gnus-summary-goto-unread to nil, and then there is no way to move to
+ the next or previous unread article.
+
+ This one has two sub-tasks. Providing the commands is one thing,
+ finding out useful key bindings for them is another. I think we
+ could provide the commands first while not changing the behavior of
+ the key bindings; then different people can experiment with
+ different key binding schemes until we find something which suits
+ many people.
+
+* `Move to next/previous/first article' is a misnomer, since ticked
+ articles are also unread but not moved to by these commands. Should
+ the terminology be fixed or the documentation, or what?
+
+* Allow sorting of threads by newest article rather than by root of
+ thread. Consider the following thread structure:
+
+ root1 Jan 1
+ leaf1 Jan 4
+ root2 Jan 2
+ leaf2 Jan 3
+
+ These two threads are sorted this way because root1 is older than
+ root2. I want an option to sort them the other way round because
+ leaf1 is newer than leaf2.
+
+* Improve editing of MIME messages. I would like to use html-mode to
+ edit the body of a text/html message, and enriched-mode for
+ text/enriched messages, and so on. This should go for multipart
+ messages as well. This is probably a hard one since Emacs currently
+ does not allow several major modes per buffer. But maybe it would
+ be nice to hack Emacs to provide this infrastructure so that Gnus
+ can make use of it? This would also make it possible to provide
+ nifty commands for editing the headers, for example, rather than
+ relying on commands which do the same thing everywhere.
+ message-x.el is really just a half-assed attempt at doing it, and
+ while it is useful, that's not the way it should be done.
+
+ I think Francisco Potort\e,Al\e(B already did something like this?
+
+* Provide commands for editing MML tags. For example, there could be
+ a command mml-add-tag-attribute which prompts me for an attribute
+ name (with completion, from the set filename, type, ...), and then
+ for a value. (This is like `C-c +' in psgml.) Or there could be a
+ command which showed me all the attributes in an MML tag and allows
+ me to use TAB to move between them, and then to edit each attribute
+ value. (This is like `C-c C-a' in psgml.)
+
+* Have Gnus automagically set group parameters for mailing list
+ groups. For example, if I have a splitting rule that automatically
+ sorts ding@gnus.org into mail.ding, then Gnus should clue in, set
+ the to-list parameter to 'ding@gnus.org', and set total-expire.
+ (This is probably Hard (TM). And of course the user should be able
+ to configure what parameters exactly get set.)
+
+* Along the same lines, automagically detect broken reply-to's. (But
+ don't auto-detect users legitimately setting a reply-to header that
+ points back to the list.)
+
+* Make it easier to change parameters on a set of groups,
+ e.g. set/clear gcc-self on process-marked groups.
+
+* Make it easier/possible to migrate between primary select-methods,
+ if that concept is going to be kept. Right now I have only one
+ group on my primary server, and I'd kind of like to change from nntp
+ to nnml, but apparently this doesn't work well.
+
+* Make it possible to refer to uniquely-named groups without</
projects / gnus / blobdiff