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