texi/ChangeLog: Synch with Emacs trunk.

[gnus] / todo

;; Also know as the "wish list".  Some are done. For the others, no
;; promise when to be implemented.

* 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 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.

* Agent:

* A better interface to the agent download scoring rules, like the one
  for the other scoring rules.

* Editing of messages in the agents cache.
  
* 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.

* 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.]

* 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.

* 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.