Rant - Emacs mail is not user friendly

[Kelly Dean]

Yesterday I decided to try using Emacs for email. For sending messages to my 
mail server, I'll use a separate program, so I need Emacs just for composing 
messages, inserting headers including autogenerated Date and Message-ID 
headers, encoding file attachments, and moving completed messages from my 
drafts folder to my outbound queue. Section 32.4.1 (Mail Sending) of the manual 
says to read feedmail.el to learn how to do this.

feedmail.el says:
;; After a long list of options below, you will find the function
;; feedmail-send-it. Hers's the best way to use the stuff in this
;; file:
;;
;; Save this file as feedmail.el somewhere on your elisp loadpath;
;; byte-compile it.  Put the following lines in your init file:
;;
;;     (setq send-mail-function 'feedmail-send-it)
;;     (autoload 'feedmail-send-it "feedmail")
;;
;; If you plan to use the queue stuff, also use this:
;;
;;     (setq feedmail-enable-queue t)
;;     (autoload 'feedmail-run-the-queue "feedmail")
;;     (autoload 'feedmail-run-the-queue-no-prompts "feedmail")
;;     (setq auto-mode-alist (cons '("\\.fqm$" . mail-mode) auto-mode-alist))
;;
;; though VM users might find it more comfortable to use this instead of
;; the above example's last line:
;;
;;     (setq auto-mode-alist (cons '("\\.fqm$" . feedmail-vm-mail-mode) 
auto-mode-alist))

Um, ok. Done. Though it's already in Emacs's loadpath by default, and already 
byte-compiled, so I skipped that part. I don't know what a VM is in this 
context, or why the alternative setting might be more comfortable, so I'm 
ignoring that part and just hoping it won't be a problem. I searched for 
⌜feedmail-vm-mail-mode⌝ and found:
⌜If you are a VM user, you might like feedmail-vm-mail-mode, though you
really don't need that (and it's not particularly well-tested).⌝

Next:
;; If you are using the desktop.el library to restore your sessions, you might
;; like to add the suffix ".fqm" to the list of non-saved things via the 
variable
;; desktop-files-not-to-save.

I found ⌜FQM stands for feedmail queued message⌝, so why wouldn't I want those 
to be saved? No explanation. Skipping this part.

Next:
;; If you are using message-mode to compose and send mail, feedmail will
;; probably work fine with that (someone else tested it and told me it worked).
;; Follow the directions above, but make these adjustments instead:
;;
;;     (setq message-send-mail-function 'feedmail-send-it)
;;     (add-hook 'message-mail-send-hook 'feedmail-mail-send-hook-splitter)

Am I using message-mode? Section 32 (Sending Mail, as opposed to Mail Sending 
in section 32.4.1) of the manual says ⌜To send an email message from Emacs, 
type C-x m⌝. That runs compose-mail, which creates a buffer in message-mode, so 
apparently I am. Ok, adjustments made.
Except there doesn't appear to be a message-mail-send-hook, so I omitted that 
part. The docstring for ⌜feedmail-mail-send-hook-splitter⌝ says ⌜Facilitate 
dividing `mail-send-hook' things into queued and immediate cases⌝, which isn't 
a feature I need since I'll only be queuing (no immediate sending), so I guess 
it won't be a problem that there's no hook to put it on.

Next:
;; If you use message-mode and you make use of feedmail's queueing
;; stuff, you might also like to adjust these variables to appropriate
;; values for message-mode:
;;
;;     feedmail-queue-runner-mode-setter
;;     feedmail-queue-runner-message-sender

The docstring for the first var says ⌜A function to set the proper mode of a 
message file⌝. It also says ⌜Most people want `mail-mode'⌝, and that's the 
default, so I guess I don't want to adjust it. Similarly for the second var.

Ok, C-x m, write a test message, C-x C-s, C-c C-s RET C-x k RET. It adds the 
appropriate headers, and in ~/mail/q/ I get a fqm file, yay. Except, it still 
has the ⌜--text follows this line--⌝ from the draft, so it isn't ready for 
sending. Why? Dunno.
And the draft is still in ~/Mail/drafts (capitalized ⌜Mail⌝, not lowercase 
⌜mail⌝ like for the queue, for no apparent reason), which is illogical, since 
the message has already been completed and queued for sending, and leaving a 
copy in drafts will just confuse me later about which messages have or haven't 
already been sent. To decide whether I want to move the draft message to 
~/mail/sent or delete the draft message and copy the queued message to 
~/mail/sent, I re-open the draft to compare it to the queued version. I notice 
the draft isn't in message-mode anymore. What if I wanted to re-send it 
(assuming it should still be in drafts in the first place)? Ok, M-x 
message-mode. C-c C-s RET C-x k RET, and it queues another.
Then I notice: re-open the draft, M-x message-mode, C-c C-s RET, but don't kill 
the buffer this time. C-c C-s RET again, and this time it asks for confirmation 
to resend, which makes sense because from Emacs's point of view, the message 
was already sent, but why didn't it ask for confirmation for the previous 
resend? Why did it forget that the message was already sent? I discover that I 
don't even have to kill the buffer to make it forget; I can just do M-x 
message-mode again. A mail program that can't remember whether it has already 
sent a message is demented. I didn't even modify the default locations for 
saving messages; it simply failed to save that flag anywhere or to record it 
implicitly e.g. by moving sent messages to ~/mail/sent.

I've already queued enough copies of this test message, so this time I answer 
‟no” to the ‟resend” question. It dumps me into the debugger (I have 
debug-on-error set to t to try to help debug all the Emacs bugs that keep 
biting me) because it's using error in a place where in modern Emacs it should 
now be using user-error, so now I have to add yet another patch to my growing 
pile of private fixes (including for actual bugs, not just user-error updates) 
that I've been asked not to submit for Emacs because saying my work is in the 
public domain isn't good enough, even though it apparently was good enough for 
the author of feedmail (see the statement ⌜This code is hereby released into 
the public domain⌝ in feedmail.el--which I never would have bothered to read in 
the first place if feedmail's documentation were in the manual).

The Message-ID header always includes 
⌜i-did-not-set--mail-host-address--so-tickle-me⌝, so I do
(setq mail-host-address "localhost")
and try again. No luck, so let's try something else. I find the 
feedmail-message-id-generator option, which says this:

⌜Specifies the creation of a Message-Id: header field.

If nil, nothing is done about Message-Id:.

If t, a Message-Id: header of a predetermined format is produced, but
only if there is not already a Message-Id: in the message.  A value of
t is equivalent to using the function feedmail-default-message-id-generator.

If neither nil nor t, it may be a string, a fiddle-plex, or a function
which returns either nil, t, a string, or a fiddle-plex (or, in fact,
another function, but let's not be ridiculous).  If a string, it
should be just the contents of the header, not the name of the header
itself nor the trailing newline.  If a function, it will be called
with one argument: the possibly-nil name of the file associated with
the message buffer.⌝

I try that. Still no luck; I still get the standard Message-ID header. Oh, but 
after reading the definition of the function feedmail-fiddle-message-id, I 
discover that despite the docstring, feedmail-message-id-generator _can't_ be 
function, but it can be a symbol fbound to a function. Ok, I change my lambda 
to a named function.
Still no luck. Digging further, I discover that feedmail-fiddle-message-id is 
only called from feedmail-send-it-immediately, which I don't use, because I'm 
only queuing, not sending immediately. Did the docs say that 
feedmail-message-id-generator wouldn't be used when just queuing rather than 
sending immediately? Of course not.

The documentation is ridiculous, it's in the wrong place, it's outdated, the 
code doesn't work, it's outdated too, and there's no point in trying to fix any 
of it because my work is unwanted anyway. Even the worst webmail service I've 
ever used was more user-friendly than this, which is why I keep using them even 
though they routinely betray me by locking me out of my account for some stupid 
little thing like lying about my niece's name because it's none of Yahoo's 
business or logging in from a new IP address and failing to tell Google about 
it in advance, forcing me to create new account and lose any mail stored in the 
previous one that I didn't paranoidly download an offline copy of after every 
mail session in anticipation of their inevitable betrayal. At least Google let 
me back in after I traveled back to where I could log in from the previous IP 
address again. I'm telling you all this in order to waste your time from 
reading this message so you'll feel my pain, or will at least tell me you do 
and I'll vote for you or something.