Hacker News Reader

FWIW, the text under "Fewer Distractions" is about using mails in old-school pull mode, where it's you who decides when the e-mails will be fetched from the server, and most importantly, without any notifications. That's truly distraction reducing, and I've adopted the latter part (no attention-grabbing notifications) for myself too.

(Except the little Outlook popup on my work laptop, because I can't be bothered to make Outlook stop displaying it.)

> Just use Gmail and spend the time on something more worthwhile.

The point of all these "let's use Emacs for ..." articles is that, if you're already using Emacs, it won't take you that much more work to decrappify your life elsewhere. The UX we're inflicting on regular people is atrocious and extremely inefficient, and the reason people make Emacs into their personal OS is precisely to buy back time and sanity they'd regularly bleed out interacting with the computing world "the right way".

Like, sure, I'd use GitHub PRs because they're more obvious to someone not used to patchsets, but does anyone regularly works on their code using GitHub's built-in in-browser editor? No, it's much, much more efficient and ergonomic to limit interactions with GitHub to `git fetch`, `git pull` and `git push`, and do everything locally with your text editor/IDE, and local repo management. The same applies to other tasks used regularly - a powerful, ergonomic interface beats the toy interfaces developed for casual users.

(I mentioned Outlook before. I hate its occasionally unpredictable IMAP behavior, frequent failures on fetching mail or calendar data (unless you're connected to MS Exchange system, then it works like a charm), and various other quirks. I still like it more than GMail's web interface, or really, any other web interface to e-mail.)

> if you're already using Emacs, it won't take you that much more work to decrappify your life elsewhere.

But, alas, it often does take more work, and often a lot more. It's gotten better lately with things like (use-package...) but the old yarn about a user's .emacs file being like a lightsaber that you have to make yourself, no one else can use it, takes a long time, and requires constant attentions and many failures to get even close to usable is no less true now than it has been since its inception. Email is HTML now, emacs isn't great at it. Use the right tool.

> The die-hards who still, in 2020, complain about HTML email are just wrong and absurd.

I understand not liking HTML email, but I agree that complaining about it is unnecessary. For one thing, in my experience practically no message of any importance whatsoever is in HTML. I could simply not read any HTML email and no-one would ever notice.

Of course, this is isn't true for everyone: while I have no first hand experience of this, there are apparently some work environments were people receive HTML email that actually is important for them to read. If the formatting isn't too complex, say, just a few headings, italic text and images, then rendering it in Emacs with shr works just fine. For more complex HTML that Emacs can't handle, Gnus has K H, which opens it right away in a browser window.

Now, if you feel pressure to send HTML email, not just to read it, then you can use one of several Emacs packages to write in Org mode or Markdown and have it automatically converted to HTML and sent as email. I actually do this sometimes for math-heavy emails and it works just fine (my previous system for that was to send people PDFs).

> Contrary to what they say, HTML email is very useful for discussing code: e.g. the ability to send well-presented syntax-highlighted code fragments for discussion is helpful, not a hindrance.

OK, that I disagree with but just because color schemes are highly personal. It's more comfortable to read that code in your own text editor, with your preferred color scheme. Doing so is easier if you were reading the email inside your text editor to begin with.

> Gnus has K H, which opens it right away in a browser window.

When doing this mind that HTML engines in many mail clients are limited. However when using the default browser the mail can run JavaScript and can remote load images, which allows tracking when you read the message.

Oh, good point! Good thing I never need to read HTML email, then.

> You will waste a LOT of time getting it set up and fiddling with it.

I'm always a bit surprised by people claiming Gnus is hard to configure. When I decided to try Gnus, I opened the manual and it says which variables to set:

    (setq 
     user-full-name "My Name"
     user-mail-address "my.email@address"
     send-mail-function 'smtpmail-send-it
     smtpmail-smtp-server "smtp.gmail.com"
     smtpmail-stream-type 'starttls
     smtpmail-smtp-service 587
     gnus-select-method
     '(nnimap "gmail"
              (nnimap-address "imap.gmail.com")
              (nnimap-server-port 993)
              (nnimap-stream ssl)
              (nnmail-expiry-wait immediate)))

Must have taken less than 10 minutes to setup. Haven't touched that configuration since then.

Now, many people complain about the difficulty of setting Gnus up, so it must be true. My best guess is that what is actually hard to setup is external mail fetching and indexing. I've never tried that. Were offlineimap and dovecot hard to setup?

I don't paticularly feel the need for external fetching and indexing: Gnus is already much, much faster than loading the Gmail webapp, and is comparable in speed to using the web app's reload button (not the browser reload button).

Now, many people also complain that fetching mail with Gnus is slow, so it must be true. My best guess here is that either they are comparing to something much faster than Gmail or they have a very different email usage pattern than I do. Maybe they keep a lot of email in their inbox?

Maybe it's better now. Many years ago I sat down to properly make a move from whatever email client I had, to gnus. I wasted a lot of time. While I got it working pretty fast it glitched repeatedly. I just wanted a working email client in emacs, I couldn't get that, I gave up.

(Edit: deleted, read the article first, dickhead)

(I don't like HTML email either, but that's a separate issue)

I'm an emacser, but I have never touched gnus purely because I have no idea how to make a dynamic link towards an email in my org projects file.

With gmail, I simply copy the URL and mark it up under my project headline in the org file.

How do you do that with gnus?

When you are looking at the email in gnus C-c l (org-store-link) then in the org file C-c M-l (org-insert-last-stored-link)

I think. I'm not sure what you mean by dynamic link and have personally never needed to link to emails.

Minor point: org-store-link comes with no keybinding, C-c l is something you chose in your config (I use C-c s).

I also wonder hat "dynamic" means in dynamic link.

This is not the first time someone has corrected me about default emacs keybindings. Considering that I probably set up that keybinding 15 years ago, it sure feels to me like it's part of emacs. I guess the next time I am trying to give some advice I need to do some software archeology on my .emacs first.

I went down the rabbit hole mostly as an ideological thing. Everything I do with a computer that isn't video or shopping (so anything that has anything to do with being productive) is centered around the idea of navigating, reading and/or manipulating text.

Most tools today seem to try their best to destroy that experience. Emacs does not. My main gripe is that Emacs isn't enough of an operating system. I don't like having to leave. The thought of an expanded Emacs with a unified GUI centered around text is for me almost a wet dream.

I have been running EXWM (emacs window manager) on top of GNU Guix for a few weeks now, and while it’s not perfect, it’s the closest I’ve come yet. I also use eshell as my default shell, so except for when running icecat (Firefox), next (Common Lisp based webbrowser), mpv for the odd video, or alacrity when eshell is not enough, everything is just emacs buffers and it’s actually great.

I have almost the same setup, except use the vterm emacs package as my backup shell instead of alacrity - while vterm doesn't integrate with emacs as well as eshell (no redirecting into buffers/calling elisp functions), I prefer it to an external shell, as I can keep my emacs bindings in the shell and share the kill ring.

Thank you for mentioning vterm! It is just what I have been looking for!

I'll add my two cents. I use emacs for email (mu4e+mbsync) and having used Thunderbird, Claws, Gmail, Roundcube (probably many others), emacs is, without a doubt (for me) the fastest way to launch/read/search/reply emails.

I can launch an emacs email client in 1/10th of a second, and it takes me straight to my inbox which is setup to highlight the emails I'm interested in. Opening an email to read is again 1/10th second (thanks to mbsync). Finally search via mu4e/xapian is blindingly fast (faster than gmail). For me, the competitors aren't even close.

Genuinely curious what your life is like such that an email app that takes longer than 1/10th of a second is just beyond the pale? Are you really that time poor?

It's really nice to have fast response clients. .1 or .3 seconds doesn't matter in the sense of saving 1000 seconds a day probably, but immediate response from tools is useful.

gmail is significantly slower: it's not like 1/10th of a second vs 3/10th of a second.

Unrelated to the topic, but:

> Just use Gmail

If you don't care about privacy and monopolies.

Then just use Fastmail or similar, but that's not his point.

or speed of the interface for that matter

> Just use Gmail and spend the time on something more worthwhile. The die-hards who still, in 2020, complain about HTML email are just wrong and absurd. Contrary to what they say, HTML email is very useful for discussing code: e.g. the ability to send well-presented syntax-highlighted code fragments for discussion is helpful, not a hindrance.

> Really, I feel the same way about projects that insist on doing development by email.

Wait. HTML email is useful for reviewing code, but you don't like when code reviews are done over email? Which is it?

I see no reason for HTML email to exist, but I've stopped trying to fight that.

Emacs is far superior to any email client for editing text. And so is VI for that matter. I've used a setup to send emails from Emacs (but not receive/view them). For that, Mutt and something like Notmuch are far more useful.

Even today, even though I mostly use Outlook (because management, I have no excuse if I miss a meeting because my client didn't properly parse the Outlook invite), I still find it useful to compose long emails in Emacs and then just paste them on the editor.

I do agree that a full email setup on Emacs can be a waste of time for most people.

> HTML email is useful for reviewing code, but you don't like when code reviews are done over email? Which is it?

I said HTML email is useful because it allows you to send syntax highlighted code to a friend. A chilled out, normal friend. I, err, wouldn't like to try getting Linus or emacs-core devs to review my patch sent as syntax-highlighted HTML.

Yes. The normal way to do it is to send the whole file as an attachment.

That way, they can open it in their favorite editor with their favorite tabs setting and key bindings and... Favorite syntax highlighting theme -- who are you to force your own color scheme on others !?

They can also easily diff it against their own copy and maybe reformat it to their preferred indentation scheme.

Meh, Emacs can already syntax-highlight code, and it'll use the colors I've already chosen as the best for my taste. Your pre-highlighted html won't do that.

> The die-hards who still, in 2020, complain about HTML email are just wrong and absurd.

Change that to people who complain about email not being only plain text, and I'd agree. In hindsight it should have been obvious from the moment it got named "email" instead of "etelegram" that people were going to want rich formatting--if they could print it on paper and send it in the physical mail they would want to be able to skip the paper and send it via email.

It's not obvious, though, that HTML was the best format to use for rich email formatting so I think there is room for someone to complain about it without automatically being wrong and absurd.

> "Fewer Distractions"

I think the time between typing emacs on the command line to being "correctly" in the editor gets a disproportionate amount of developer attention.

(I have F2 mapped to "edit emacs startup file")