Re: Wishlist for oGnus

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

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

* Go through the todo list and remove items already done.

* 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 between nnfolder and nnml: have more than one article
  per file, but more than one file per group.  With .overview files.

* .overview files for nnfolder?

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

So much to do...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)