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... :)
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.
At least on the web side of things I completely understand why people opt for editors like VS Code and Atom. It’s because they only need to learn 1 language. The barrier for entry to all different parts of the JS ecosystem is greatly lowered by everything sharing a common language. JS developers can use javascript
- On the frontend
- On the backend
- In their build process
- In plugins and tooling
- Install like you do for other apps on your operating system
- Type code in it (you can already type in the rest of your operating system just fine, using CUA standards)
- Save and open files as you expect, manage multiple files like you manage tabs in a web browser
In other words, you can get going and add complexity when you feel the need for it; but you're not confronted with knowing it as a prerequisite, and missing 'table-stakes' features (e.g. syntax highlighting for all common languages) without messing around in a niche editor specific language.
Well, look at the home page for Atom. It describes itself as "a text editor that's modern, approachable, yet hackable to the core."
They then call out features like cross platform editing, a package manager, smart autocompletion, file system browser, multiple panes, find and replace, themes and customization. If this list defines what they mean by "modern" then Emacs has been modern since before modern was a thing text editors needed to be.
However "approachability" is the one characteristic that stands out because it's subjective and that's telling. I would guess most people who aren't already familiar with Emacs find it daunting, just a little bit too different from the rest, and I can see a natural reluctance to invest time in learning something so different if the outcome (how productive will I be?) is unclear.
> 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'.
When my employer turned off the company-internal Jabber server in favour of, out of all things, Hipchat, I moved my team mates to IRC. (They also seem to all know at least some vi, even the trainee.)
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].
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.
Oh, I love Gnus. Do you use Gnus? The code is a bit messy. It needs a huge refactoring. Things have accumulated some cruft since first version, released in 1987.
It's also a bit slow unless you run a local Dovecot instance, which I dislike.
Magit and Org are Emacs killer applications. I wish we could fund some developer to refactor Gnus and port some ideas from Notmuch.
I agree with all of the above! I do use it, and am working on refactoring it (very slowly). I wrote a generalized search language for it a few months ago, which relieved some of the searching pain, but it is waiting for another rather large code update to go in before it can land.
I've been looking at how to clean up and "modernize" the code over the past few weeks, and hopefully will slowly start making commits. I've got a roadmap document I might try to add to the Emacs repo.
Awesome! Maybe if you think you have good ideas you should seek some funding from the community after your code gets a bit of momentum.
What do you think about nnir-notmuch?
Aside, don't you think it'd be easier to reimplement a big chunk of Gnus based on the principles of Notmuch? That is, make everything work on tags only and delegate all tags-to-files mapping to a backend (possibly written on some expressive Elisp DSL)?
Asking for money might be a bit much! It's still Lars' package, after all, and no one has asked for money for it so far. Plus, I'd be afraid of the "you broke it, you bought it" policy – I don't want to be responsible for the whole thing! Just the servers and groups and marks bit of it. And search, I guess. I'm just planning on making incremental changes.
What you describe about reworking Gnus to be more like Notmuch wouldn't necessarily take that much work. Gnus doesn't do any searching itself, it just delegates to a search engine like Notmuch or Mairix or the built-in IMAP engine. Gnus and IMAP are very much married to the idea of groups/folders, but none of the other search engines are. They return their results regardless of group/folder, and then Gnus actually goes to the work of filtering out results that aren't in the selected group(s).
All that's needed is to make it easier for the user to launch a search of an entire server, without forcing them to select which groups to use. This would suck for IMAP searches, but work just fine with other search backends.
If Andy Cohen's work on nnselect could land, then I could finish work on the generalized search backend. That would allow you to issue a single search against different backends (say a local maildir indexed with Notmuch, and a remote IMAP server). The search would be translated for the different backends, and all the results displayed together in one group.
Sounds great to hear there's some active development going on Gnus! As a user I was a bit upset with things slowing down.
I look forward to testing all these new search improvements.
Thanks for taking the time to write this up. I tried to hack a bit on Gnus, but I admittedly found the codebase quite overwhelming compared to Mu4e or Notmuch, which are an order of magnitude simpler and thus easier.
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.
Well, notmuch doesn't delete messages itself by design. But you can delete messages by other means, using tags to designate the messages you want deleted. This really doesn't seem to be a big hurdle.
"cannot have copies in multiple folders ... no notion of folders"
I hear people talking about notmuch and folders a lot, and I can understand why if they're still using other clients to access their mail -- clients that can't deal with mail using just tags. But if you've moved completely to using notmuch, then using tags only and forgetting about folders seems like the way to go.
"cannot apply a tag to an individual message without passing by the threaded view first"
If you have the message open, you should be able to apply a tag to it using (notmuch-show-add-tag).
That said, I have my own gripes with notmuch:
Notmuch doesn't have scoring, it doesn't have BBDB integration, it has no way to get arbitrary message headers from elisp, it only indexes a handful of headers, it can't do regex searches of everything.
If you're using IMAP, deletion is a thing. I often get people sending me huge stuff I have no intention to keep or sync. I need to be able to sync the deletion flag. This is a one line change I did myself and used for a long time, but it doesn't get merged because as messages are currently indexed by message-id, tagging a message for deletion might involve more than one actual underlying message.
I also use folders as a mean to exclude useless stuff from syncing. Spam is the most glamorous example: I do not sync spam. I was able to get spam to be moved in/out according to a tag, but only with afew, and again with other issues involved. Doable, but again, ...
Also, notmuch in emacs is very much thread oriented. But with email, I found the behavior very annoying. People will mail you in response to a 1yr old message, and notmuch will happily bring and show the thread from something which is completely unrelated. I found myself switching in/out of tree mode too often, and then just gave up.
I actually enjoyed (and still enjoy) Gnus much more. It's just more efficient for large message volumes. It shows you what's _new_ by default, which notmuch doesn't seem to get right.
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.
25 comments
[ 2.1 ms ] story [ 28.3 ms ] threadIs this related to the proliferation of JavaScript libraries and hip new languages? I honestly don't know.
- On the frontend - On the backend - In their build process - In plugins and tooling
There’s something to be said for that.
- Install like you do for other apps on your operating system
- Type code in it (you can already type in the rest of your operating system just fine, using CUA standards)
- Save and open files as you expect, manage multiple files like you manage tabs in a web browser
In other words, you can get going and add complexity when you feel the need for it; but you're not confronted with knowing it as a prerequisite, and missing 'table-stakes' features (e.g. syntax highlighting for all common languages) without messing around in a niche editor specific language.
They then call out features like cross platform editing, a package manager, smart autocompletion, file system browser, multiple panes, find and replace, themes and customization. If this list defines what they mean by "modern" then Emacs has been modern since before modern was a thing text editors needed to be.
However "approachability" is the one characteristic that stands out because it's subjective and that's telling. I would guess most people who aren't already familiar with Emacs find it daunting, just a little bit too different from the rest, and I can see a natural reluctance to invest time in learning something so different if the outcome (how productive will I be?) is unclear.
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'.
“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.
When my employer turned off the company-internal Jabber server in favour of, out of all things, Hipchat, I moved my team mates to IRC. (They also seem to all know at least some vi, even the trainee.)
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].
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
It's also a bit slow unless you run a local Dovecot instance, which I dislike.
Magit and Org are Emacs killer applications. I wish we could fund some developer to refactor Gnus and port some ideas from Notmuch.
I've been looking at how to clean up and "modernize" the code over the past few weeks, and hopefully will slowly start making commits. I've got a roadmap document I might try to add to the Emacs repo.
What do you think about nnir-notmuch?
Aside, don't you think it'd be easier to reimplement a big chunk of Gnus based on the principles of Notmuch? That is, make everything work on tags only and delegate all tags-to-files mapping to a backend (possibly written on some expressive Elisp DSL)?
What you describe about reworking Gnus to be more like Notmuch wouldn't necessarily take that much work. Gnus doesn't do any searching itself, it just delegates to a search engine like Notmuch or Mairix or the built-in IMAP engine. Gnus and IMAP are very much married to the idea of groups/folders, but none of the other search engines are. They return their results regardless of group/folder, and then Gnus actually goes to the work of filtering out results that aren't in the selected group(s).
All that's needed is to make it easier for the user to launch a search of an entire server, without forcing them to select which groups to use. This would suck for IMAP searches, but work just fine with other search backends.
If Andy Cohen's work on nnselect could land, then I could finish work on the generalized search backend. That would allow you to issue a single search against different backends (say a local maildir indexed with Notmuch, and a remote IMAP server). The search would be translated for the different backends, and all the results displayed together in one group.
I look forward to testing all these new search improvements.
Thanks for taking the time to write this up. I tried to hack a bit on Gnus, but I admittedly found the codebase quite overwhelming compared to Mu4e or Notmuch, which are an order of magnitude simpler and thus easier.
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.
But with good logic to implement tag-based rules, something like notmuch could be marvelous.
Well, notmuch doesn't delete messages itself by design. But you can delete messages by other means, using tags to designate the messages you want deleted. This really doesn't seem to be a big hurdle.
"cannot have copies in multiple folders ... no notion of folders"
I hear people talking about notmuch and folders a lot, and I can understand why if they're still using other clients to access their mail -- clients that can't deal with mail using just tags. But if you've moved completely to using notmuch, then using tags only and forgetting about folders seems like the way to go.
"cannot apply a tag to an individual message without passing by the threaded view first"
If you have the message open, you should be able to apply a tag to it using (notmuch-show-add-tag).
That said, I have my own gripes with notmuch:
Notmuch doesn't have scoring, it doesn't have BBDB integration, it has no way to get arbitrary message headers from elisp, it only indexes a handful of headers, it can't do regex searches of everything.
I also use folders as a mean to exclude useless stuff from syncing. Spam is the most glamorous example: I do not sync spam. I was able to get spam to be moved in/out according to a tag, but only with afew, and again with other issues involved. Doable, but again, ...
Also, notmuch in emacs is very much thread oriented. But with email, I found the behavior very annoying. People will mail you in response to a 1yr old message, and notmuch will happily bring and show the thread from something which is completely unrelated. I found myself switching in/out of tree mode too often, and then just gave up.
I actually enjoyed (and still enjoy) Gnus much more. It's just more efficient for large message volumes. It shows you what's _new_ by default, which notmuch doesn't seem to get right.
FixedMisc is still the best font