Reply inline in notmuch-show buffer, "mu4e-conversation style"

Reply inline in notmuch-show buffer, "mu4e-conversation style"

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

Hi,

mu4e-conversation (https://gitlab.com/ambrevar/mu4e-conversation) has a
very nice feature in my opinion: it allows you to compose a reply at the
end of the buffer, in a dedicated "composition area".

- Pressing C-c C-c sends the message (it won't if the message is empty
  or white space).

- Pressing "RET" appends the region to the composition area.  This
  makes it very convenient to *quote/cite from different messages*.
  With a prefix argument, it prepends a citation line (e.g. "John doe wrote...").
  This is similar to how messengers like Whatsapp work.
  This is the real killer-feature of mu4e-conversation in my opinion.

What to you people think of adding such a feature to notmuch-show?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]

What I did in mu4e-conversation was actually rather simple, albeit a bit
hackish:

- Copy the test from the composition buffer
- Save the window excursion
- Fire up a new message buffer as notmuch-show-reply would produce.
- Cleanup the citation.
- Insert the copied text from the composition buffer.
- Send.

Sadly, mu4e wraps too much around message-mode and this forced me to use
some ugly hacks.  I haven't looked at notmuch's code yet, but it seems
that it does not wrap quite as much, so it might be cleaner and as
simple as a writing a 10-line-longish function.

The "hardest" part is to add a composition area.

Here is the code excerpt from mu4e-conversation:

--8<---------------cut here---------------start------------->8---
(defun mu4e-conversation-send (&optional msg)
  "Send message at the end of the view buffer.
If MSG is specified, then send this message instead.

Most `mu4e-compose-…' variables are lexically bound during the
call of this function."
  (interactive)
  (unless (mu4e-conversation--buffer-p)
    (mu4e-warn "(send) Not a conversation buffer"))
  (let (draft-buf
        (buf (current-buffer))
        (mu4e-compose-signature mu4e-compose-signature)
        ;; [More local variables...]
        (mu4e-compose-crypto-reply-encrypted-policy mu4e-compose-crypto-reply-encrypted-policy))
    (run-hooks 'mu4e-conversation-before-send-hook)
    (save-window-excursion
      (mu4e-conversation--open-draft msg)
      (condition-case nil
          ;; Force-kill DRAFT-BUF on succcess since it's an implementation
          ;; detail in mu4e-conversation and the composition area is in BUF.
          (let ((message-kill-buffer-on-exit t))
            (message-send-and-exit))
        ;; Stay in draft buffer and widen in case we failed during header check.
        (error (setq draft-buf (current-buffer))
               (widen))))
    (cond
     (draft-buf
      (switch-to-buffer draft-buf))
     (mu4e-conversation-kill-buffer-on-exit
      (switch-to-buffer buf)
      (mu4e-conversation-quit 'no-confirm))
     (t
      ;; Delete message that was just sent.
      (goto-char (point-max))
      (mu4e-conversation-previous-message)
      (forward-line)
      (delete-region (line-beginning-position 1) (point-max))
      ;; Ensure it's writable.
      (insert
       (propertize "\n"
                   'face 'mu4e-conversation-header
                   'rear-nonsticky t))
      (set-buffer-modified-p nil)
      ;; -after-send-hook can be used to update the conversation buffer so that
      ;; it includes the message that was just sent.
      (run-hooks 'mu4e-conversation-after-send-hook)))))
--8<---------------cut here---------------end--------------->8---

The hackish part is in mu4e-conversation--open-draft, which I'm not
including here because it's long and boring.  Hopefully notmuch.el won't
require us to do this.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

Anyone interested?  Should I send a patch?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[David Edmondson]

On Wednesday, 2019-04-03 at 11:12:27 +02, Pierre Neidhardt wrote:

> Anyone interested?  Should I send a patch?

I couldn't figure out when I'd want to use this, as yanking text from
the existing notmuch-show buffer seems straightforward.

Maybe something akin to gnus-dired-mode would be interesting - it would
be used in notmuch-show mode and yank selected text into the current
message-mode buffer (including quoting).

dme.
-- 
I got a girlfriend that's better than that.

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

David Edmondson <dme@dme.org> writes:

> I couldn't figure out when I'd want to use this, as yanking text from
> the existing notmuch-show buffer seems straightforward.

You want it once you try it :)

> Maybe something akin to gnus-dired-mode would be interesting - it would
> be used in notmuch-show mode and yank selected text into the current
> message-mode buffer (including quoting).

That could work too.  We might have to store the name of the composition
buffer in a variable that's buffer-local to the notmuch-show buffer, so
that Notmuch does not get confused when composing several emails at the
same time.

Having a conversation area in the same buffer has
some benefits though:

- Less key presses to start composing.
- No need to play with buffers to display both the thread and the composition.
- The above problem disappears, there is no need to manually keep a
  relation ship between 2 buffers since there is only one buffer.

With this workflow however, we don't need to cite the previous email
when composing.  So it'd be nice to have an option to discard the
citation (I think it is a nice option in general).

This could be done with `notmuch-mua-cite-function', or, maybe better,
have a dedicated option so that `notmuch-mua-reply' does not include the
citation in the first place.

Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[David Edmondson]

On Wednesday, 2019-04-10 at 12:53:59 +02, Pierre Neidhardt wrote:

> David Edmondson <dme@dme.org> writes:
>> Maybe something akin to gnus-dired-mode would be interesting - it would
>> be used in notmuch-show mode and yank selected text into the current
>> message-mode buffer (including quoting).
>
> That could work too.  We might have to store the name of the composition
> buffer in a variable that's buffer-local to the notmuch-show buffer, so
> that Notmuch does not get confused when composing several emails at the
> same time.

gnus-dired just asks if it is unsure which of the existing composition
buffers you want to use.

> Having a conversation area in the same buffer has
> some benefits though:
>
> - Less key presses to start composing.

How? Don't I still have to hit one key?

> - No need to play with buffers to display both the thread and the composition.

If a thread is any length, I will want to split the window to show older
mail while I'm writing my comments at the bottom of the thread. So there
might only be one buffer, but two windows, so I'm not sure of the
benefit.

> - The above problem disappears, there is no need to manually keep a
>   relation ship between 2 buffers since there is only one buffer.
> 
> With this workflow however, we don't need to cite the previous email
> when composing.

Well, this presumes a particular workflow and set of mail
clients. Whether it's a good idea to top post without the bottom is
debatable, I think.

> So it'd be nice to have an option to discard the
> citation (I think it is a nice option in general).
>
> This could be done with `notmuch-mua-cite-function', or, maybe better,
> have a dedicated option so that `notmuch-mua-reply' does not include the
> citation in the first place.
>
> Thoughts?
>
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/

dme.
-- 
All those lines and circles, to me, a mystery.

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

David Edmondson <dme@dme.org> writes:

> How? Don't I still have to hit one key?

No, you just start writing at the end of the buffer, this area is then
marked as writable.

>> - No need to play with buffers to display both the thread and the composition.
>
> If a thread is any length, I will want to split the window to show older
> mail while I'm writing my comments at the bottom of the thread. So there
> might only be one buffer, but two windows, so I'm not sure of the
> benefit.

True.  But if the thread is not that long, or if we only want to look at
the last thread, then we don't need to.  With a separate buffer, we
always have to play with the buffers to display them side by side, for instance.

> Well, this presumes a particular workflow and set of mail
> clients. Whether it's a good idea to top post without the bottom is
> debatable, I think.

I'm confused: can it be top-posting if there is no citation?

Citations don't offer much guarantee in terms of data integrity.  If
someone wants to read the previous message, they should open the
previous message, regardless of the workflow / client I think.

All this can be made optional and configurable.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[David Edmondson]

On Wednesday, 2019-04-10 at 13:52:25 +02, Pierre Neidhardt wrote:

> David Edmondson <dme@dme.org> writes:
>
>> How? Don't I still have to hit one key?
>
> No, you just start writing at the end of the buffer, this area is then
> marked as writable.

Understood.

>>> - No need to play with buffers to display both the thread and the composition.
>>
>> If a thread is any length, I will want to split the window to show older
>> mail while I'm writing my comments at the bottom of the thread. So there
>> might only be one buffer, but two windows, so I'm not sure of the
>> benefit.
>
> True.  But if the thread is not that long, or if we only want to look at
> the last thread, then we don't need to.  With a separate buffer, we
> always have to play with the buffers to display them side by side, for instance.

Yes.

>> Well, this presumes a particular workflow and set of mail
>> clients. Whether it's a good idea to top post without the bottom is
>> debatable, I think.
>
> I'm confused: can it be top-posting if there is no citation?

I was struggling to express myself :-)

Perhaps “without any context” would be better.

> Citations don't offer much guarantee in terms of data integrity.  If
> someone wants to read the previous message, they should open the
> previous message, regardless of the workflow / client I think.
>
> All this can be made optional and configurable.

Yes. My argument was not that we shouldn't have this, just that I wonder
if it results in a good workflow for people who are not using
notmuch/mu4e/gmail (or any other client that shares the same kind of
thread view).

dme.
-- 
Leaves are falling all around, it's time I was on my way.

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

David Edmondson <dme@dme.org> writes:

> Yes. My argument was not that we shouldn't have this, just that I wonder
> if it results in a good workflow for people who are not using
> notmuch/mu4e/gmail (or any other client that shares the same kind of
> thread view).

With about 1 year of experience using mu4e-conversation, I found that it
works really well, actually better in most cases since it does not
"pollute" emails with forgotten citations.

Most people use Gmail or clients that support threading, in which case this is
really a good fit.

But really if we think about the workflow of "most people", then most of
the time citations are ignored (e.g. top-posting) and just pollute the
rest of the emails.  In those cases (the majority?) a non-threaded
workflow does not really work I think.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[David Edmondson]

On Wednesday, 2019-04-10 at 15:27:14 +02, Pierre Neidhardt wrote:

> David Edmondson <dme@dme.org> writes:
>
>> Yes. My argument was not that we shouldn't have this, just that I wonder
>> if it results in a good workflow for people who are not using
>> notmuch/mu4e/gmail (or any other client that shares the same kind of
>> thread view).
>
> With about 1 year of experience using mu4e-conversation, I found that it
> works really well, actually better in most cases since it does not
> "pollute" emails with forgotten citations.

Encouraging people to trim their replies is an ongoing burden, I agree.

> Most people use Gmail or clients that support threading, in which case
> this is really a good fit.

90% of my email is via my employer. There is no Gmail there, and most
people are not using a threaded mailer. In general they are used to
inter-mingling their comments in replies rather than top-posting or not
quoting (but this is definitely changing over time, with top-posting
becoming more common).

> But really if we think about the workflow of "most people", then most of
> the time citations are ignored (e.g. top-posting) and just pollute the
> rest of the emails.  In those cases (the majority?) a non-threaded
> workflow does not really work I think.

I've no problem with their being more options.

dme.
-- 
Stranded starfish have no place to hide.

Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

All good!
Then I'll submit a patch to bring mu4e-conversation features to notmuch :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]