mu4e vs notmuch

[Saša Janiška]

Hello,

the other day I was watching several presentations (Prot) about Emacs -
I want to "migrate" a few more apps to it - and one was about notmuch...

I've become "enlightened" that it makes sense not to be som much
concerned about the mail folders and its structure, but it's more
important to quickly find what one wants and I'be become enthusiastic
about notmuch, but the realized that mu4e can be used in a similar/same
manner. :-)

Being, in general, familiar with both mailers my conclusion is that, in
comparison with notmuch, mu4e does provide few advantages:

- I already have a working setup and therefore no need to fiddle with a
new package

- its database can be easily and quickly rebuilt at any time

- it does provide support for (re)filing of messages and therefore
eliminates the need to use external tooling/scripting to achieve the
same thing

Yes, notmuch's tagging can be nice, but actually all I want is to be
able to tag certain messages with some custom tag(s) and then to query
for them...

Do I miss something?


Sincerely,
Saša

--
A person is said to be elevated in yoga when, having renounced
all material desires, he neither acts for sense gratification
nor engages in fruitive activities.

[Yuri D'Elia]

On Sun, Jan 02 2022, Saša Janiška wrote:
> Yes, notmuch's tagging can be nice, but actually all I want is to be
> able to tag certain messages with some custom tag(s) and then to query
> for them...
>
> Do I miss something?

I did use notmuch for a while. I suggest you do the same and figure out
which one you like best.

For me, notmuch by itself was "not enough". I had to extensively add
rules using afew to make it interesting.

There was a big insistence to operate on entire threads/result sets, but
for email I often want to operate on a single message, with threads
being an exception. Refiling is something I do regularly on mu4e, but
was a lot more convoluted to do with surrogate tags when bi-di sync is
involved.

Overall, mu4e feels like a much more polished mail client that I could
customize having most of the features you can expect out of the box,
while notmuch felt like more like an opinionated search interface that
could also be used to write messages. However, if you like the
thread-based user-interface, it can work just fine.

I fully agree on the tags. I definitely wish I could attach and search
for tags in mu4e programmatically. I could implement a whole slew of
features on top of it, like killing threads and custom priorities.
However, tags do not substitute well for features like directory
hierarchies as notmuch does. I feel like mu4e doesn't have this
limitation, and could use tags very effectively.

Also note that you can use gnus as an email client backed by the notmuch
index. Essentially gnus+nnir+notmuch replaces the notmuch emacs
component with gnus, and works in a very similar way: you operate on
ephemeral groups built with a search query. Gnus should not be
underestimated. I used it as an nntp+email client for a decade. It has
the most powerful summary buffer I tried, although you might get lost in
customization.

[Saša Janiška]

Yuri D'Elia <wav...@thregr.org> writes:

Helo Yuri,

> For me, notmuch by itself was "not enough". I had to extensively add
> rules using afew to make it interesting.

I must congratulate you for very insightful email I haven't received for
quite some time!

> There was a big insistence to operate on entire threads/result sets, but
> for email I often want to operate on a single message, with threads
> being an exception.

Same here. I'm not following linux-kernel and such mailing lists. ;)

> Refiling is something I do regularly on mu4e, but was a lot more
> convoluted to do with surrogate tags when bi-di sync is involved.

I fully agree and like mu4e's ability to refile.

> Overall, mu4e feels like a much more polished mail client that I could
>customize having most of the features you can expect out of the box,

Do you use Emacs' with vanilla bindings or, possibly, evil-mode?

>while notmuch felt like more like an opinionated search interface that
>could also be used to write messages. However, if you like the
>thread-based user-interface, it can work just fine.

I'm with you here!

> I fully agree on the tags. I definitely wish I could attach and search
> for tags in mu4e programmatically.

That would be great, indeed.

> However, tags do not substitute well for features like directory
> hierarchies as notmuch does. I feel like mu4e doesn't have this
> limitation, and could use tags very effectively.

Who knows, maybe one day, although my feeling is that Dirk is not very
fond of them. :-)

> Also note that you can use gnus as an email client backed by the notmuch
> index. Essentially gnus+nnir+notmuch replaces the notmuch emacs
> component with gnus, and works in a very similar way: you operate on
> ephemeral groups built with a search query. Gnus should not be
> underestimated. I used it as an nntp+email client for a decade. It has
> the most powerful summary buffer I tried, although you might get lost in
> customization.

I've working Gnus setup and the above paragraph makes me think...so,
I'll have to give it a try, although I believe that by deploying
something like https://github.com/rougier/mu4e-dashboard to make my
mu4e's screen a bit simpler withouth being overloaded with all those
folder shortcuts, it is going to be good-enough. ;)


Sincerely,
Saša

--
Those who are on this path are resolute in purpose,
and their aim is one. O beloved child of the Kurus,
the intelligence of those who are irresolute is many-branched.

[Saša Janiška]

Yuri D'Elia <wav...@thregr.org> writes:

> Also note that you can use gnus as an email client backed by the notmuch
> index. Essentially gnus+nnir+notmuch replaces the notmuch emacs
> component with gnus, and works in a very similar way: you operate on
> ephemeral groups built with a search query.

I just wonder if one can still use notmuch's tags within Gnus?


Sincerely,
Saša

--
From wherever the mind wanders due to its flickering and unsteady
nature, one must certainly withdraw it and bring it back under
the control of the self.

[Yuri D'Elia]

On Sun, Jan 02 2022, Saša Janiška wrote:

>> There was a big insistence to operate on entire threads/result sets, but
>> for email I often want to operate on a single message, with threads
>> being an exception.
>
> Same here. I'm not following linux-kernel and such mailing lists. ;)

I occasionally have to.

I'm using sieve server-side to move all non-critical lists to a separate
folder. I then sync such folders more rarely with mbsync using different
cron schedules.

I was initially moving each list to a different subfolder. But since
I've wrote the mu4e-jump-to-list extension I now "bin" them by sync
frequency since list autodiscovery is just faster to use: no server-side
rule is necessary when subscribing: I just have a catch-all bulk/list-id
rule at the end of the pipeline.

Although mu4e threading is not as powerful as gnus', IMHO it still gets
the job done pretty well.

> Do you use Emacs' with vanilla bindings or, possibly, evil-mode?

I probably wouldn't be able to use a vanilla configuration at this point
;), but I never got along too well with evil-mode. But I'm actually
using vi (neovim) for all non-programming tasks. Not sure how I ended up
this way, but well... My vi configuration is quite short though.

>> However, tags do not substitute well for features like directory
>> hierarchies as notmuch does. I feel like mu4e doesn't have this
>> limitation, and could use tags very effectively.
>
> Who knows, maybe one day, although my feeling is that Dirk is not very
> fond of them. :-)

I think the real power of tags comes from the ability to program them.
That is, "afew" make it click for me. Without that, I kind-of agree that
tags bring "just" another refiling category.

If Dirk is reading, "afew" is a simple rule-based tag engine. The idea
is to match messages based on tags and apply more tags as a result. The
script is run usually after fetching or syncing messages.

For example, the "new" tag can be a proxy from the new flag, like
"read", "old", etc.

Imagine a few hypothetical rules: automatically kill old threads you
never even read once (very useful for mailing lists):

- search for: messages with "ignored" tag with date:+30days
- search for: all related messages in the same threads
- in the cumulative result set:
- remove "new" flag
- add "ignored" tag

(I had such a rule with afew). Now in mu4e, you see a thread you want to
kill? Just add a custom action to add the "ignore" flag.

Another rule, which is also useful for mailing lists, is to raise
priority of threads you participated. As above:

- search for: messages with "replied" tag
- search for: related messages
- in the result set:
- apply "highlight" flag

Then, in mu4e, add a rule to color/change the face of messages with a
tag. If flags synthesize standardized tags, then colorization becomes
uniform (the replied/old/deleted faces become a consequence of tags, and
everything follows more easily).

> I've working Gnus setup and the above paragraph makes me think...so,
> I'll have to give it a try, although I believe that by deploying
> something like https://github.com/rougier/mu4e-dashboard to make my
> mu4e's screen a bit simpler withouth being overloaded with all those
> folder shortcuts, it is going to be good-enough. ;)

I'm still using gnus with gmane for bigger lists.

The mu4e headers buffer is not as convenient as gnus (custom thread
splitting/gathering functions, as well as scoring, is something I miss),
however the ability to quickly search and narrow-down a query has more
than offset the limitations.

I'm using folders heavily, however I never look at the dashboard/hello
screen. I have a few complex queries bound to bookmarks I'm using with
the mu4e-query-fragments extensions I jump to in most cases, which
aggregate results from multiple folders.

When changing and customizing views is so fast, I simply stopped looking
at overview screen: it's directly "overview results" for me.

[Saša Janiška]

Yuri D'Elia <wav...@thregr.org> writes:

> I was initially moving each list to a different subfolder. But since
> I've wrote the mu4e-jump-to-list extension I now "bin" them by sync
> frequency since list autodiscovery is just faster to use: no server-side
> rule is necessary when subscribing: I just have a catch-all bulk/list-id
> rule at the end of the pipeline.

Ohh, I'll take a look!

> I probably wouldn't be able to use a vanilla configuration at this point
> ;),

Well, I meant Emacs bindings vs evil-mode. :-)

> but I never got along too well with evil-mode.

Thanks.

> But I'm actually using vi (neovim) for all non-programming tasks. Not
> sure how I ended up this way, but well... My vi configuration is quite
> short though.

:-)

> If Dirk is reading, "afew" is a simple rule-based tag engine. The idea
> is to match messages based on tags and apply more tags as a result. The
> script is run usually after fetching or syncing messages.

Yeah, afew looks really interesting...

> - search for: messages with "ignored" tag with date:+30days
> - search for: all related messages in the same threads
> - in the cumulative result set:
> - remove "new" flag
> - add "ignored" tag

It would bring quite a new dimension to mu4e!

> I'm still using gnus with gmane for bigger lists.

I believe that for my usage of mailing lists, I'll settle fully on
mu4e. ;)

Thanks a lot for helping me to decide!


Sincerely,
Saša

--
Before giving up this present body, if one is able to tolerate
the urges of the material senses and check the force of desire and
anger, he is well situated and is happy in this world.