Re: Missing nntp-request-create-group message when sending emails

[Steinar Bang <sb@dod.no>]

>>>>> Steinar Bang <sb@dod.no>:

> Here's the stack trace:
> Debugger entered--Lisp error: (error "No such function: nntp-request-create-group")
>   signal(error ("No such function: nntp-request-create-group"))
>   error("No such function: %s" nntp-request-create-group)
>   gnus-get-function((nntp "news" (nntp-address "nntp.dod.no")) request-create-group)
>   gnus-request-create-group("Deleted Items")
>   nnmail-expiry-target-group("Deleted Items" "drafts")
>   nnmh-request-expire-articles((104) "drafts" nil t)
>   apply(nnmh-request-expire-articles ((104) "drafts" nil t))
>   nnoo-parent-function(nndraft nnmh-request-expire-articles ((104) "drafts" nil t))
>   nndraft-request-expire-articles((104) "drafts" nil t)
>   message-disassociate-draft()
>   message-send(nil)

If I'm to guess, the above looks like, that when deleting the draft, it
ends up trying to expire articles in some non-existing folders, and then
it tries to create those folders on the primary server, which, being an
NNTP server, doesn't allow it.

So the questions are:
 1. why does deleting a draft attempt to expire articles on the primary
    server
 2. why does expiring articles try to create a new folder (sounds like a
    very bad idea in all circumstances)

I also think I see where the "Deleted Items" comes from.  It's in the
secondary select method for an nnimap Exchange server:
	(nnimap "work"
		(nnimap-address "exchange.work.com")
                (nnmail-expiry-target "Deleted Items"))

Appearently nnmail-expiry-target isn't server local.  It really should
be, since expiring to a folder is something I'd really only do if that's
what the server, and other clients on the server expects.

>   message-send-and-exit(nil)
>   call-interactively(message-send-and-exit)

> This explains two other effects I've seen:
>  - There's always a copy stored in the drafts folder after the error
>  - It seems to have been happening with messages that have been a while
>    being edited, and not ones that have been quickly created and sent
>    (it's been happening to autosaved messages)

> I've found a way to reproduce it consistently: just save the message
> before sending.

> There was also an annoying side effect from the debugging.  After the
> stack trace I could no longer reply to messages.  All I got was 
>  nndraft-open-server: Wrong type argument: stringp, nndraft-directory
> in the mini-buffer.

> Stopping Gnus and restarting, just caused the message to appear during
> startup, and Gnus never to start properly.