notmuch.el and replying to multiple emails at once

notmuch.el and replying to multiple emails at once

[Matt Armstrong]

A feature I miss from Gnus is being able to reply to multiple emails at
once.  Has anyone else found to be a missing feature?  I wonder if it
would be easy to add to notmuch's Emacs MUA.

Background: In Gnus' equivalent to notmuch.el's tree mode it is possible
to "mark" multiple messages at once in a manner similar to dired for
directory contents.  Gnus has a number of different operations that can
be performed on messaged so marked.  One is reply.  When replying to
multiple messages at once, the In-Reply-To: header is set appropriately,
and the quoted contents of each is right there in the message buffer.

I used to use this feature of Gnus frequently, especially in busy
threads.  I often find multiple messages that need replying to, but that
replying in one message tends to be more effective than scattered
replies to multiple messages.

Problem is, I can't think of an unobtrusive way to add this to notmuch
without adding a lot of machinery.

Re: notmuch.el and replying to multiple emails at once

[Alexander Adolf]

Matt Armstrong <matt@rfc20.org> writes:

> A feature I miss from Gnus is being able to reply to multiple emails at
> once.  Has anyone else found to be a missing feature?

I have, and support your request.

But not only to reply, but more generally to act on (tag, reply,
forward) multiple emails.

Of course I can select multiple _contiguous_ lines in a search result
list, or tree view, and do something with these messages
(`notmuch-search-tag` being an obvious example). But not when my
selection is (or would be) non-contiguous.

> I wonder if it would be easy to add to notmuch's Emacs MUA.
> [...]
> Problem is, I can't think of an unobtrusive way to add this to notmuch
> without adding a lot of machinery.

Perhaps the problem can be split into smaller pieces?

I think one piece could be to enable the user to select multiple regions
(think e.g. zones.el [1]), which could be a problem entirely separate
from notmuch.el?

[1] https://www.emacswiki.org/emacs/Zones

The second piece could be to extend notmuch.el to make use of multiple
regions, and implement more functions that act on such regions. Since
there doesn't seem to be a "standard way" of doing non-contiguous
regions in Emacs, one third-party "multi-region package" (e.g. zones.el)
would need to be picked, and notmuch.el made to detect it's availability
and make use of it.


Looking forward to your thoughts,

  --alex

Re: notmuch.el and replying to multiple emails at once

[Jose A Ortega Ruiz]

On Tue, Nov 08 2022, Alexander Adolf wrote:

> Matt Armstrong <matt@rfc20.org> writes:
>
>> A feature I miss from Gnus is being able to reply to multiple emails at
>> once.  Has anyone else found to be a missing feature?
>
> I have, and support your request.
>
> But not only to reply, but more generally to act on (tag, reply,
> forward) multiple emails.
>
> Of course I can select multiple _contiguous_ lines in a search result
> list, or tree view, and do something with these messages
> (`notmuch-search-tag` being an obvious example). But not when my
> selection is (or would be) non-contiguous.
>
>> I wonder if it would be easy to add to notmuch's Emacs MUA.
>> [...]
>> Problem is, I can't think of an unobtrusive way to add this to notmuch
>> without adding a lot of machinery.
>
> Perhaps the problem can be split into smaller pieces?
>
> I think one piece could be to enable the user to select multiple regions
> (think e.g. zones.el [1]), which could be a problem entirely separate
> from notmuch.el?
>
> [1] https://www.emacswiki.org/emacs/Zones
>
> The second piece could be to extend notmuch.el to make use of multiple
> regions, and implement more functions that act on such regions. Since
> there doesn't seem to be a "standard way" of doing non-contiguous
> regions in Emacs, one third-party "multi-region package" (e.g. zones.el)
> would need to be picked, and notmuch.el made to detect it's availability
> and make use of it.

In notmuch-tree at least, this can be implemented, i think, in a much
simpler way.  There (and i guess in any other search list), every line
in the buffer represents a message, and there is already a record (as
text properties) describing the message (its id, subject, tags,
filename, even indentation level in my outline extension).  It'd be
pretty easy to add a new "marked" flag to those properties, that could
be added by a simple key shortcut in the same way Gnus does (adding on
top of that addition of contiguous messages in a region is again
trivial).  It's also not much more complicated to add things like
"select all messages in this thread".  With that selection mechanism in
place, one could at any moment ask for the list of marked messages and
their properties, which contain all the information needed to perform
operations such as replies or tagging (the latter being much easier to
implement; the part about multiple replies needs a bit more work, but
possibly one could re-use whatever functions gnus is already providing
to compose the reply buffer--notmuch already uses some of those
facilities).

Would make for a neat weekend project for someone with a bit of time in
her hands :)

Cheers,
jao
-- 
To kill time is not murder, it's suicide. -William James (1842-1910)

Re: notmuch.el and replying to multiple emails at once

[Dan Čermák]

Jose A Ortega Ruiz <jao@gnu.org> writes:

> On Tue, Nov 08 2022, Alexander Adolf wrote:
>
>> Matt Armstrong <matt@rfc20.org> writes:
>>
>>> A feature I miss from Gnus is being able to reply to multiple emails at
>>> once.  Has anyone else found to be a missing feature?
>>
>> I have, and support your request.
>>
>> But not only to reply, but more generally to act on (tag, reply,
>> forward) multiple emails.
>>
>> Of course I can select multiple _contiguous_ lines in a search result
>> list, or tree view, and do something with these messages
>> (`notmuch-search-tag` being an obvious example). But not when my
>> selection is (or would be) non-contiguous.
>>
>>> I wonder if it would be easy to add to notmuch's Emacs MUA.
>>> [...]
>>> Problem is, I can't think of an unobtrusive way to add this to notmuch
>>> without adding a lot of machinery.
>>
>> Perhaps the problem can be split into smaller pieces?
>>
>> I think one piece could be to enable the user to select multiple regions
>> (think e.g. zones.el [1]), which could be a problem entirely separate
>> from notmuch.el?
>>
>> [1] https://www.emacswiki.org/emacs/Zones
>>
>> The second piece could be to extend notmuch.el to make use of multiple
>> regions, and implement more functions that act on such regions. Since
>> there doesn't seem to be a "standard way" of doing non-contiguous
>> regions in Emacs, one third-party "multi-region package" (e.g. zones.el)
>> would need to be picked, and notmuch.el made to detect it's availability
>> and make use of it.
>
> In notmuch-tree at least, this can be implemented, i think, in a much
> simpler way.  There (and i guess in any other search list), every line
> in the buffer represents a message, and there is already a record (as
> text properties) describing the message (its id, subject, tags,
> filename, even indentation level in my outline extension).  It'd be
> pretty easy to add a new "marked" flag to those properties, that could
> be added by a simple key shortcut in the same way Gnus does (adding on
> top of that addition of contiguous messages in a region is again
> trivial).  It's also not much more complicated to add things like
> "select all messages in this thread".  With that selection mechanism in
> place, one could at any moment ask for the list of marked messages and
> their properties, which contain all the information needed to perform
> operations such as replies or tagging (the latter being much easier to
> implement; the part about multiple replies needs a bit more work, but
> possibly one could re-use whatever functions gnus is already providing
> to compose the reply buffer--notmuch already uses some of those
> facilities).

FTR, David Bremner suggested a workaround along those lines in
id:87o7z31iwp.fsf@tethera.net (email from Wed, 08 Jun 2022 08:41:58 -0300)