Re: [PATCH v3 5/5] emacs: Use message-citation-line-format in reply

[Aaron Ecay <ecay@sas.upenn.edu>]

On Thu, 19 Jan 2012 21:46:46 -0700, Adam Wolfe Gordon <awg+notmuch@xvx.ca> wrote:
> On Thu, Jan 19, 2012 at 11:45, Aaron Ecay <ecay@sas.upenn.edu> wrote:
> > Shouldn’t this just use message-insert-formatted-citation-line?
> 
> Yes, good idea.  I just tried this and it almost works.  The only
> issue is that the default message-mode-citation-line-format has a
> newline at the end, and this function inserts an *additional* newline,
> so we end up with a blank line before the beginning of the quoted
> text.  This is fixable by the user, of course, but it means the
> default out-of-the-box setup will create funny-looking replies, which
> is probably bad.  Thoughts?

(let ((message-citation-line-format
       (remove ?\n message-citation-line-format)))
  ...)

(Or, if you think someone might have a newline other than at the end of
the string, you could do something a little more complicated to remove
only a newline at the end.)

Or you could introduce a new defcustom
‘notmuch-message-citation-line-format’ (with newline-less default), and
let-bind m-l-c-f to that value.  But that is pretty ugly – we don’t want
to have to “wrap” every variable whose default we don’t like.

> I've also tried using message-cite-original to create the reply body,
> and it also almost works.  The issue, again, is one of defaults.  In
> addition to the blank line I mentioned above, the default
> message-citation-line-function inserts the "plain" citation line "Foo
> <foo@bar.baz> writes:" instead of the formatted one.  This is a big
> change from the current notmuch default.
> 
> If everyone's OK with this and willing to customize it themselves,
> then I'm happy to go with this solution, but I'm pretty reluctant to
> change the default in such a significant way.

I’m personally of the opinion that notmuch should just say “the mail
composition facility is provided by message mode (here is the
documentation on customizing it)”.  Message mode is 8,000 lines of
elisp.  We have the choice to:
- write our own message composition mode
- wrap (as explained above) the default message-mode variables we don’t
  like in notmuch-prefixed variants, with suitable let-bindings.
- use only the parts of message-mode that we like
- pass composition off to message mode

The first option just doesn’t make sense.  The second is also a little
nuts.  The third is what we are trying now, but it’s painful – the
message mode code has its own structure and its own defaults, which
don’t always agree with notmuch’s.  I am in favor of the fourth –
notmuch’s elisp code should pass data to message mode in the most low
level form it can, and let message mode do any extra work in the way
it already does.  And users should customize message composition via
message mode, not notmuch.  There’s a tradeoff to this approach – by
controlling more within notmuch, we can have nicer defaults at the
expense of more brittle code and/or fewer user-visible customizations.

This is not in any way a criticism of your work (which is great) –
you’re right that you need “permission” to uproot the defaults, and I’m
advocating for it to be given.

One possible step that might ease the transition pain could be for
notmuch’s emacs interface to have a configuration file (similar to
Wanderlust’s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is
that this file contains elisp code, and is loaded by notmuch the first
time any notmuch-related commands are invoked by the user.  If the file
does not exist, notmuch could create it with default content that sets
message-citation-function, message-citation-line-format,
message-yank-prefix (to get rid of the ugly default whereby message-mode
indents the original message by four spaces instead of inserting “> ”),
etc.  If there is interest in this approach, I’d be happy to work on a
patch for it.

I’ve sort of stumped for this idea before
(id:"m239bgcd1d.fsf@gmail.com") and it didn’t exactly get rave reviews.
So I’ll shut up if it’s really not something people want to see.

I’ll close with an example of a nice feature that message mode has
(which I’ve been really wanting since the reply keybindings changed)
that notmuch would get for free if it hooked into message mode better:
the function message-widen-reply takes a reply-to-sender message and
makes it reply-to-all.

-- 
Aaron Ecay