
Nevermore: an experimental Emacs interface for Notmuch - pmoriarty
https://github.com/tjim/nevermore
======
gonewest
Just last week, some of us were reminiscing in Slack about reading mail and
Usenet via emacs. It’s amusing and a little unsettling to find the emacs/vi
debate has been abandoned because you’ve gotten to the age where your
colleagues have never experienced either... :)

~~~
zeveb
That's something I don't get: _why_ don't they use either? For decades new
programmers were exposed to one or both, and they sorted themselves more-or-
less by their affinity for one or the other style of text editing. But now
they don't seem to be exposed to vi & emacs, and chase Big New Things™ which
inevitably don't deliver either a rich, full-featured editing language (as
with vi) or absolute power & extensibility (as with emacs).

Is this related to the proliferation of JavaScript libraries and hip new
languages? I honestly don't know.

~~~
mschaef
> That's something I don't get: why don't they use either?

The other way to look at that question is to consider who the developers were
back then and what alternatives they had. Emacs or vi compares very well at
first glance to a tool like ed... but maybe not so much when side by side with
Eclipse, etc. It's a harder sell these days, and that's only more true when
you consider all the language/ecosystem integration you get from a modern IDE.

Emacs and vi also tend to be the kinds of tools that reward long-term study
and practice. I don't know this for a fact, but I'd guess that with the
massive increase in the prevalence of developers over the last 30-40, that
it's brought in huge number of people that have little to no interest in
learning the vi editing language, Emacs Lisp, etc.

> absolute power & extensibility (as with emacs).

As a 25 year Emacs user, I question the 'absolute power' bit... there's a lot
of magic that's easy out of the box in IntelliJ or Eclipse that's quite
difficult in Emacs... Maybe the situation could be different in theory, but
it's not right now and many people have many good reasons for focusing on the
'right now'.

~~~
mirabilos
meh, give me ed over vi and emacs any day

“modern” seems to be a curse word these days, all the time I find it being
used it’s used to describe something despicable like the systemd ecosystem.

------
girzel
I wish the Github page said something (anything) about how this is different
from/better than Emacs' existing Notmuch client...

~~~
usernam
Hopefully this is actually a MUA, and not a search interface with message-mode
sprinkled on top?

I tried using notmuch on emacs as my primary mail client for several months,
but it falls short on so many things (just to name one: cannot delete
messages, cannot have copies in multiple folders, cannot apply a tag to an
individual message without passing by the threaded view first, no notion of
folders, and so on...). You can work around most of those, but it's just a
work-around.

It's right that it's "not much" of a client. Notmuch combined with afew is
incredibly powerful as a backend. But it's not a particularly good mail
client.

You can use notmuch efficiently with neomutt, which is a great combination
(excellent MUA with fast backend).

But for something closer to a real client on emacs itself, mu4e is much
better. It supports identities out of the box, and has no silly limitations
imposed by blind message-id indexing. Unfortunately, mu (the backend) has no
concept of batch tag processing, which made certain operations very convenient
[one thing I did was killing threads I didn't care about - currently
impossible to do with mu alone].

~~~
nextos
I share your frustrations with Notmuch as an Emacs client. But I still find it
better than Gnus and Mu4e. And I have tested all 3 extensively aside from
using Mutt for a decade.

I think making the Notmuch interface "pure" is a great design decision. By
pure I mean that it just operates on tags, but never deletes or moves files
and it doesn't even know about folders.

This gives it great flexibility. You can implement virtually any logic in a
Maildir backend by remapping tags to actual files. Any arbitrarily complicated
workflow, silencing, automated scoring like what Gnus offers, etc. is possible
while the UI will be the same. Just tagging.

The problem is that Notmuch developers do not bundle any tools for
implementing such a backend with notmuch, and third party stuff like afew [1]
is lacking. It reminds me a bit about the situation with address completion.
For a long time, mu offered this, while notmuch relied on hacky third party
scripts.

[1] [https://github.com/afewmail/afew](https://github.com/afewmail/afew)

~~~
usernam
I still think notmuch is a great backend, but a poor client. Despite using
mu4e, I still find Gnus superior in terms of pure reading efficiency (I
_still_ use Gnus regularly with gmane). Scoring and thread handling is just
superior.

There's a lot to gain from adaptive scoring alone.

In fact, I also switched over mu4e after trying a search backend for Gnus, and
I've been oscillating from mutt/gnus/mu4e a lot over more than a decade.

Tagging is powerful, but I find it too constrained as a single tool to manage
everything.

~~~
nextos
Yes, right now Gnus is probably the best option.

But with good logic to implement tag-based rules, something like notmuch could
be marvelous.

------
racer-v
Cool, will this work well with proportional fonts? I'd like to go back to
using Emacs for mail but I've gotten used to reading the mail body in
Thunderbird or the browser, and going back to monospace is a bit jarring.

~~~
mirabilos
Eh, you can use a fixed-width font in GUI apps, too. In Kontact, for example,
you just press “x”.

FixedMisc is still the best font

------
krapans
It looks like it's abandoned. :/

