Setting up Gmail in Doom Emacs using mbsync and mu4e

Mu4e can render HTML e-mails in Emacs (using Emacs’ shr render engine). Works well enough for most cases. When it doesn’t, there is a command for opening the message in your browser of choice. Re sending HTML: I personally think it’s a bad idea and don’t do it. But I think it‘s possible to write e-mails in org mode markup and them have them automatically converted to HTML. Probably easy to build something similar for Markdown, if it doesn’t exist yet.

I am proficient with emacs, but I've never gotten to the point where org-mode clicks. Any advice?

And for Gmail specifically you might want to look at the mbsync option PipelineDepth

As noted in the .mbsyncrc gist:

> The value is "used to limit average bandwidth consumption (GMail may require this if you have a very fast connection)." Turns out the same is true for iCloud. There's probably some optimized value greater than "1" that can be used, but this works for me.

I actually have it set to 5 now.

I did, I used spacemacs for a few years, but switched to Doom at the beginning of 2020. It is dramatically faster in start up and usage. I also find the configuration a lot easier and straightforward. I did the initial switch because Java LSP was stalling out spacemacs constantly.

I tried, when Spacemacs was somehow broken on my system. I didn't find anything better on Doom, and fixing Spacemacs was easier than switching to Doom. Using Doom, most of your muscle memory from Spacemacs is gone because not everything is configured the same (that is of course normal). But not all, and that make the experience weird to me.

I also feel like Spacemacs is growing faster and has more feature than Doom, because more dev's are working on Spacemacs. But I might be wrong about that.

I switched. Doom starts much faster and feels generally snappier and more minimal. I like the configuration system. I use this Spacemacs module for Doom[0] to retain (most of) the Spacemacs keybindings and some of the functionality.

[0] https://github.com/chenyanming/spacemacs_module_for_doom

I can confirm a lot of what has already been said. I've used spacemacs since 2017, have contributed to it, and have written several private layers for it, such as a custom org layer.

But I switch to Doom emacs literally two weeks ago and I'm never going back. I find doom to be much faster not just startup time but in general responsiveness (one major exception: hitting SPC and waiting for key binding tips to show seems to be much slower in doom than spacemacs). Other than that I found doom to be much easier to configure and much more configurable.

The major selling point for me was that in doom emacs there is much much less ceremony in wrapping a new package in a module, and more importantly it is _easier_ to reuse documentation for those packages because most packages provide configuration examples using `use-package` anyway. My only hangup was less documentation around writing custom modules which took me about a day to figure out (I would advise to just read some of the source code or mimic a module that doom ships with).

YMMV, but if you feel like you've attained a certain level of emacs maturity, I would 100% recommend trying it out. Be prepared that some modules, like the haskell module, don't ship with a lot of keybindings so you'll have to set those up yourself.

I got into to emacs again about six months ago. Having not used it for about a decade, Spacemacs was a wonderful introduction to what is possible in Emacs today. I’ve since moved on to a personal straight/use-package based init with a relatively minimal package set centered on the vertico/embark ecosystem, but I remain fond of spacemacs and still look to it for ideas.

Really, I’m surprised we haven’t seen Prot on the front page here.

I’ve gone in this direction after using Spacemacs for a couple of years. I’ve found

- Startup speed much quicker though I do use emacsclient so this is only an issue on first launch

- Overall feels a lot more snappy

- Simpler and more straight forward configuration

- Updates seem to break less (though sadly this isn’t reduced to zero, just reduced).

sweet, thanks. looks like you pretty much got there before me. i wonder what it is about doing this that makes people want to blog about it ...

mu4e is mail on steroids. If you need to automate anything you can grok a small script in an afternoon (much less if you are familiar with elisp) and have it work for you in ways no other mail agent will.

My need: write personalized exams for my (50-ish) students, send an email for each with his respective exam, and upon receiving the replies, save each attachment in its own directory.

Some perl+latex+mu4e+elisp ans voilà.

Edit: I refuse to use my Uni’s version of moodle for long-reply exams. Also using pdftools has changed my life.

I have found that running the html email through w3m generates usable text in almost all cases:

    text/html;    w3m -I %{charset} -T text/html; copiousoutput;

... in your .mailcap. The result is usually better than what ends up in in the text portion of dual text/html emails. Particularly nice when someone thinks they need html to show a table.

I switched to mbsync from offlineimap about four years ago. I was having issues with offlineimap hanging during sync, as well as slow performance in general.

I switched to mbsync and have had zero issues since. Just set it and forget it.

I switched from offlineimap to mbsync. I can't remember the details, but I remember having lots of various issues with offlineimap but I can't remember any issues with mbsync other than once I think I had to change something in my config after an upgrade.

Better to just have two or more Emacs processes running. One for programming, one for email, one for Elfeed. If I had to check email in Emacs, I might do it this way, but like you I just use Tbird and Emacs.

Do you mean for fetching? I've got offlineimap set up for mine, and it's primarily a background task, because Emacs is not dealing with it directly.

Using mu4e, it is more of an interface to that local store with its built-in search API.

I'm not sure if the gmail interface is instantaneous or if it's just using tricks to make it seem that way.

I've regularly waited up to a minute for an email I've just sent to arrive on someone else's account. A large part of this delay seems to be for some weird undo feature they've added which you can no longer fully disable.

10-30 seconds sounds very slow indeed. It used to be slow for me (over 10 seconds against my university server), but I discovered it was because I had not deleted emails and propogated that to the server, I had only marked them for deletion (d), not deleted (D), and so there was some kind of syncing back and forth each time of quite many emails with mbsync. For me now it is always under 5 seconds for syncing and indexing, usually quicker.

I've found the sequential syncing with mbsync to be a major bottleneck. These days instead of "mbsync -a" I have a script like this, using GNU Parallel:

    parallel --bar -j0 mbsync "$@" <<EOF
    mail1
    mail2
    mail3
    EOF

Does https://support.google.com/accounts/answer/185833?hl=en not work?