Hacker Timesnew | past | comments | ask | show | jobs | submitlogin
Trying Gnus as an Email Client (gluer.org)
70 points by ingve on May 21, 2023 | hide | past | favorite | 46 comments


I switched from (neo)mutt to Gnus and never looked backed.

Gnus has a much nicer user experience and the integration into Emacs alone is worth switching.

What I particularly like: I can use the native IMAP server-side search with Gnus' own syntax. This means I have never been tempted to look at search/index specialized clients like notmuch or mu4e.

https://www.gnu.org/software/emacs/manual/html_node/gnus/Sea...

EDIT: Oh, what I forgot: also very nice is the Email Based Diary for reminders that appear in the groups overview. Quite unknown and covered by countless other tools, but the solution (and again - integration) is really clever.

https://www.gnu.org/software/emacs//manual/html_node/gnus/Em...


I'm curious how you had such great luck with Gnus IMAP. I'm a Gnus user myself, but I had to switch to local Maildir because I couldn't get a workable experience with the IMAP configuration. Specifically, Gnus would freeze Emacs for several minutes every time I loaded Gnus. This mostly seemed to be a problem when I accessed an account with more than 10,000 items in a mail folder.

Running the same folder in a local Maildir didn't cause an issue, so I made the switch, but it would be nice to go back to IMAP. Partially back to IMAP, anyway - the office Outlook server requires OAUTH for IMAP and I don't believe that GNUS supports that configuration.


Using Fastmail and nnimap in Gnus, I only block for about 1 sec to check emails. I tried my Gmail account, but results were much worse, several secs.


I have even more items in the INBOX of one IMAP account but never faced the issues you described. Maybe my configuration (parts of it) helps:

  (setq gnus-select-method '(nnnil nil))
  (setq gnus-secondary-select-methods
      '((nnimap "account1"
                (nnimap-address "mail.account1")
                (nnimap-server-port "imaps")
                (nnimap-stream ssl)
                (nnir-search-engine imap)
                (nnmail-expiry-target "nnimap+account1:Trash")
                (nnmail-expiry-wait immediate))
        (nnimap "account2"
                (nnimap-address "imap.account2")
                (nnimap-server-port "imaps")
                (nnimap-stream ssl)
                (nnir-search-engine imap)
                (nnmail-expiry-target "nnimap+account2:Trash")
                (nnmail-expiry-wait immediate))
        (nndiary "diary")))


The gnus search syntax from (setq gnus-search-use-parsed-queries t) is great.


I used it for years until one day it corrupted its own cache and become thoroughly unusable. Manually repairing tens of megabytes of serialised Lisp isn't fun or practical. If you live in Emacs, it's a great tool though.

Sadly, I had to move on to Thunderbird, and lately Outlook. Sad to say it, but email has become an absolute pain to use and text-based email clients are increasingly unusable. At some level, I feel I'm a sell-out. I no longer self-host my own email server, and I no longer use Gnus or mutt. It does feel like the rest of the world has forced us off these high-quality clients as it has consolidated around a small number of providers who deliberately prevent us doing it ourselves or using our own clients without jumping through major hoops like authentication, and this is a big loss.


If "cache" means .newsrc.eld, 10s of MB seems rather large. I wonder what the corruption was, since it doesn't sound like anything I can remember in ages using Gnus. .newsrc.eld does have backups in the same way as other files.

If you're missing XOAUTH2 authentication, there is an Emacs auth-source backend for it.


Yes, it was the newsrc.eld which got corrupted. I can't remember the circumstances, but I think it was an Emacs or Gnus bug at that time. This would be over 10 years ago though.


I have the exact same experience. Migrated from mu to thunderbird due to problems with modern email and lately one of the organizations I work for migrated from imap so that thunderbird also has become unusable.


If that means O365/Exchange with IMAP turned off, I don't remember about Thunderbird, but Evolution works, or see https://hackertimes.com/item?id=36023845


Don't forget to try BBDB, which is a great contact manager, much more productive than anything I've used since.

https://www.emacswiki.org/emacs/BbdbMode

At one point, I had it exporting to the original Palm PDA: https://www.neilvandyke.org/bbdbpalm/

If you later move your email away from Emacs: https://www.neilvandyke.org/bbdb2tbird/


The one problem I had with BBDB is that there isn’t a single shred of decent documentation that I was able to find. I stumbled on EBDB [1], a port of BBDB to the EIEIO framework, which actually has easy to find docs.

[1]: https://github.com/girzel/ebdb


I had to quit Thunderbird because its search never found the email I was looking for.

But Gnus is really good for email. I think it's gotten a lot of bad press in the Emacs community for being slow and leaky. But the imap backend re-write, async, and native-comp have made Gnus fast enough for my taste.


I've been using Emacs for more than a quarter century, 99.9999% of the time text-only (whether Linux console, X terminal console, xterm, or SSH client) on a remote server. My email client is VM, written in Emacs Lisp. I've used it to read mail for almost as long as I've used Emacs. I tried Gnus a couple of times for Usenet but stayed with slrn because of Emacs's lack of multithreading.

I've never tried Gnus for email because VM has always met my needs. VM (and ancillary tools, like Personality Crisis and mairix)

* does a great of job displaying HTML messages. For the very few that it doesn't, one keystroke sends the message to my web browser running locally.

* sends URLs I select (all from the keyboard) to the web browser

* opens images and attachments

* auto-adjusts the From: line of outgoing messages depending on the recipient

* archives messages to various folders using various criteria

* searches my archived mail going back a quarter century at lightning speed

Of course, I can write Emacs Lisp code of my own to extend any or all of the above.

VM isn't perfect. I'm sure that I could do all of the above with Gnus, and quite possibly am missing out on other features that VM lacks. Overall, though, I really feel like I have a superpower for email handling with it.


It's interesting that this user was using notmuch before Gnus. I switched notmuch.el+notmuch to Gnus+notmuch last year, i.e., I kept using notmuch but I switched from notmuch's own Emacs frontend to Gnus's support for notmuch.

It takes Gnus ten minutes to start up even with nativecomp, and hours to do its initial indexing (but you already have to give up that time for notmuch's own indexing). It's unusable without nativecomp.

I switched because I realised that I was hackily reimplementing many Gnus features and ideas on top of notmuch.el in my Emacs init. I had to fix some bugs in Gnus, and help the author of nnselect fix some much harder bugs, over the past nine months. It works well now.


Wow. For me, Gnus starts in <10s. But I guess it depends a lot on what backends you use (I use dovecot+mbsync for mail, so Gnus doesn't really index anything)


I started using Gnus back when the ding rewrite was released, primarily for news then for email as well to get away from the hellish Lotus Notes client. The unified experience, with scoring and threading was a real boon. At some point I shifted to Outlook because I was getting so much html and office docs filling my email. I am back to using Gnus for consuming the Linux kernel mailing lists as newsgroups where the plaintext aesthetic and the article scoring really helps.


This is one thing on my list to do. But I am curious about this statement:

>shifted to Outlook because I was getting so much html

Does that mean GNUs does not handle html email ? I ask because with the standard ew package, I would think it would be able to format some html emals.

Right now, I use mutt but under some occasions I need to start firefox to read these emails. Usually from medical companies.


It does handle HTML, but it'll look different from what people reading email in Firefox etc. see. So just like with eww.

(Also, Outlook has MS-specific niceties like replying directly to Teams messages from within an email without having to start up Teams, which I assume they made as a workaround for how long it takes to start up Teams and pick the right organisation and wait for it to tell you to log out (since your account is still connected to that one organisation that long ago invited you for a single meeting and only org admins can remove users) and then hit reload since that sometimes works and then pick the right organisation again and then reply "OK" and then quickly exit Teams before your computer runs out of memory and grinds to a halt.)


There is always the possibility to open and view a HTML Email in the browser by pressing K H.


My recollection is a bit vague, but I reckon it was not so much the html as what outlook was doing to the html.


I transferred all my Sieve rules for marking mail as read to Gnus scoring rules, but haven't made much progress beyond that. I turned on adaptive scoring, but I'm not convinced it is achieving anything. How do you make scoring useful, assuming you do mean more than just the equivalent of Sieve mark-as-read rules?


I mostly use permanent rules to increase the score of reputable contributors to the kernel mailing lists, maintainers, etc. I also use a mixture of permanent and temporary rules to increase the score of things I want to follow or decrease for things I want to ignore. Oh and I lower the score of replies, which has the effect of de-emphasising them unless they’re part of a thread that has an increased score.


I used to run mu4e with my gmail accounts, those were fun times. That unfortunately no longer seems to be possible since Gmail, Outlook and others no longer provide SMTP service in the name of two factor authentication. Keeps my blood boiling as now every email provider has its own API.

Anyway, what email providers do people use today? One I found with SMTP support tends to be directed to spambox by Gmail.


I don't know about Outlook and others, but you can still use any client you want, both for IMAP and SMTP access, using application passwords[1]. I have been doing that for years, both for Gmail and Google Workspace, without any issue.

[1] https://support.google.com/accounts/answer/185833?hl=en


Is there an option for the folks on the security that disables app passwords?


Thanks, that looks like a good solution.


I still use mu4e with gmail, offlineimap will work if you make an “app password” in gmail for it.

Sending mail works with that same app password and smpt.gmail.com, I use that to send email from systemd using msmtp as well.

It’s pretty reliable, but if you change your gmail password it revokes your app passwords. Only downtime I had was I simply didn’t know that, easy fix.


Fastmail works very well for me - for many years. Never a problem, great support.


> Keeps my blood boiling as now every email provider has its own API.

I can relate to this, I'm yet to find a way to connect my $CURRENT_JOB Office 365 to Gnus...

> Anyway, what email providers do people use today?

I personally use mailbox.org and never had a problem with SMTP.


If you need an IMAP/SMTP gateway to O365/Exchange, at least, try https://davmail.sourceforge.net/


I had to stop around the time of 2fa, as well. Hoped there was a way around that by now. (Well, not around, but with.)


2FA in what context? App passwords, XOAUTH2, Kerberos pre-auth...? OTP or FIDO? You should be able to work with them anyway.


"advanced security". It doesn't allow app passwords. At least, that used to be the case. Using security keys.


I assume that's oauth2 (which xoauth2 implies). It works for me with O365 and a Duo key for multiple clients.


Thanks for the pointer! I'll have to see if I can get that working. Last I looked at this stuff, I didn't understand oauth as well as I do now. (Which, I'm sure is still not perfect. Is an improvement, though.)

Edit: Am I correct that I have to basically make my own app in order to do this? (Ok if the case, just making sure I'm not looking in the wrong direction.)


I think you're meant to make your own app, but I don't have permission anyway. Some applications have their own tenant id (?) and you can copy, e.g. davmail's from ~/.davmail.properties, or even copy the token you get from it to use with something else.


I used gnus for email (and ERC for IRC) for a few years starting around 23 years ago. The showstopper was the lack of async I/O and multithreading in GNU emacs, so the more you do inside emacs, the more everything regularly freezes up if you want your inbox to stay up to date.

Is GNU Emacs multithreaded or async yet? It was, uh, a few years away a few decades ago.


Emacs is not multithreaded, but it has supported async/cooperative threads for a very long time (at least since before I started using it almost a decade ago). Modern packages are generally written to not block while doing something like fetching updates. Gnus still blocks. Someone rewrote it to no longer block, but it is a very large change, and GNU Emacs is unlikely to have non-blocking Gnus anytime soon. I just run Gnus with a separate daemon.


Is there any reason someone would consider switching to gnus from mu4e? I'm always open to, and quite enjoy, trying new things in emacs when it seems promising but am not familiar with the relevant differences.


I've used both. Mu4e is a lot simpler for email. I plan to eventually switch to Gnus for everything since it handles so much more than just mail (feed reader, hacker news, reddit, twitter, newsgroups, etc.), but mu4e is much easier to set up. Gnus really shines when you need to deal with a higher volume of messages than you will ever read.

Mu4e now uses Gnus' code for viewing emails by default. Mu4e's headers mode will look a lot nicer than Gnus' article mode though.

Gnus is massive and has a huge learning curve. It would be great if you are working with very active mailing lists. If you're dealing with a small amount of email, there won't be much benefit.


Thank you for the information, very useful.


I prefer Mu4e and msmtp/lbsync.


You say you prefer mu4e which seems to imply you tried or looked into gnus. What were the reasons that made you prefer mu4e? I use mu4e right now but am considering checking out gnus, would like your reasoning for doing the opposite.


Speed, speed and speed. M-x gnus-jog-cache is slow as hell, mu4e makes it fast and on Usenet slrnpull+Gnus it's the ultimate combo:

My ~/.gnus.el:

    (setq gnus-select-method '(nnspool "")
     nnspool-spool-directory "/var/spool/slrnpull/news"
     nnspool-nov-directory "/var/spool/slrnpull/news/over.view"
     nnspool-active-file "/var/spool/slrnpull/data/active"
     gnus-check-new-newsgroups t
     gnus-post-method '(nnspool "")
     nnspool-inews-program "sh"
     nnspool-inews-switches '("-c" "cat >      /var/spool/slrnqqqpull/out.going/X$(date +%s)-$$-1.$LOGNAME"))

    (defun my-slrnpull-post-only (&optional dont-check)
    (interactive)
    (when (or dont-check
             (message-news-p))
     (gnus-message 5 "Posting news...")
     (shell-command "slrnpull -d /var/spool/slrnpull --post-only")))

    (add-hook 'message-sent-hook 'my-slrnpull-post-only)
~/.slrnrc:

    set auto_mark_article_as_read 0
    set username "anthk"
    set hostname "example.org" #YOUR HOST HERE
    set realname "bozo user"
    set post_object "slrnpull"
    set read_active 0
    set scorefile "/var/spool/slrnpull/news/score"
    set server_object "spool"
    set sorting_method 9
    set spool_inn_root "/var/spool/slrnpull"
    set spool_nov_root "/var/spool/slrnpull/news"
    set spool_root "/var/spool/slrnpull/news"
    set use_slrnpull 1
    set wrap_flags 4


Sorry, I was late. Mu4e and slrn can acces your cached your remote imap and nntp folders with an mbsync (isync pkg) maildir and a news spool (slrnpull setup) respectively, so the access is ultrafast compared to the crawling GNUs, even when used with fiber connections.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: