Storing the group a message has been written to

[Kai.Grossjohann@CS.Uni-Dortmund.DE]

Lars told me that I could add stuff to nnmail-cache-insert to store
the group a message has been written to in ~/.nnmail-cache.  I expect
to be able to do useful stuff with it.

I have now produced the following horrible abomination:

,-----
| (defun nnmail-cache-insert (id)
|   (when nnmail-treat-duplicates
|     ;; Store some information about the group this message is written
|     ;; to.  This function might have been called from various places.
|     ;; Sometimes, a function up in the calling sequence has an
|     ;; argument GROUP which is bound to a string, the group name.  At
|     ;; other times, there is a function up in the calling sequence
|     ;; which has an argument GROUP-ART which is a list of pairs, and
|     ;; the car of a pair is a group name.  Should we check that the
|     ;; length of the list is equal to 1? -- kai
|     (let ((g nil))
|       (cond ((and (boundp 'group) group)
|              (setq g group))
|             ((and (boundp 'group-art) group-art (listp group-art))
|              (setq g (caar group-art)))
|             (t (setq g "")))
|       (unless (gnus-buffer-live-p nnmail-cache-buffer)
|         (nnmail-cache-open))
|       (save-excursion
|         (set-buffer nnmail-cache-buffer)
|         (goto-char (point-max))
|         (insert id "\t" g "\n")))))
`-----

This depends on the fact that nnmail-cache-insert is called
(indirectly) from nnchoke-request-accept-article which sets GROUP-ART
or from nnmail-split-incoming which sets GROUP.

Two questions:

(1) This is truly horrible, one should not depend on such an
    obfuscated fact.  Any suggestions for improving this?

(2) The group name is not unique.  Sometimes the group name is
    `drafts' which comes from the nndraft server, sometimes the group
    name comes from the normal nnml server.  I want to use this for
    mail splitting.  Mail splitting deals with one backend only.
    Thus, I would need to find out whether the group concerned is from
    that backend and to ignore it if it doesn't come from the backend
    where mail splitting is done.

kai
-- 
Life is hard and then you die.