[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Rant - Emacs mail is not user friendly
From: |
Kelly Dean |
Subject: |
Rant - Emacs mail is not user friendly |
Date: |
Sat, 15 Nov 2014 06:54:07 +0000 |
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.
- Rant - Emacs mail is not user friendly,
Kelly Dean <=