7 ms·

Write Gmail in Emacs the Easy Way: gmail-message-mode

68 points by lelf 12y ago

arohner 12y ago
I recently started using mutt, connecting to GMail w/ IMAP. It's been working pretty well. I'm still really interested in a full mail client that supports all of gmail's features (labels, archiving, etc), and works well with Emacs.
- nextos 12y ago
  Gmail's implementation of IMAP is quite broken (and the XMPP/Jabber one too!). But you can achieve a local setup which rivals with Gmail by combining mutt and/or notmuch/mu and isync (mbsync). And it's quite possible to keep it sync'ed with Gmail, although there might be some rough edges. Personally, I don't thing tags are that useful if you have a fast and expressive local search engine like notmuch or mu (xapian-based), but YMMV.
- rakoo 12y ago
  I suggest you take a look at sup (http://supmua.org/ http://supmua.org/). Its goal is to transpose the gmail experience on your terminal. I've been working with the maildirroot branch [0] which mimics the IMAP installation of GMail, so you can use a standard OfflineIMAP to sync between your computer and GMail, and still use all the power of tagging/archiving/searching on your computer. Oh and it has a few niceties, the most important one to me being native support of gpg. Disclaimer: I'm one of the maintainers. [0] https://github.com/sup-heliotrope/sup/tree/maildir-root https://github.com/sup-heliotrope/sup/tree/maildir-root
  - gcr 12y ago
    Once you've looked at sup, take a look at Notmuch (http://notmuchmail.org/ http://notmuchmail.org/), which separates the search/indexing of incoming messages from the mail composition from sending/receiving. As a spiritual sup successor, it has a few nice clients for the command line (bower?) and various editors (Emacs, maybe a vim client too)
  - gcr 12y ago
    Once you've looked at sup, take a look at Notmuch (http://notmuchmail.org/ http://notmuchmail.org/), which separates the search/indexing of incoming messages from the mail composition from sending/receiving. As a spiritual sup successor, it has a few nice clients for the command line (bower?) and various editors (Emacs, maybe a vim client too)
- stevenrace 12y ago
  I've been using 'Mu4e' for the past few years and recommend it: http://www.djcbsoftware.nl/code/mu/mu4e.html http://www.djcbsoftware.nl/code/mu/mu4e.html
  - michaelsbradley 12y ago
    mu4e-maildirs-extension is also quite handy: https://github.com/agpchil/mu4e-maildirs-extension https://github.com/agpchil/mu4e-maildirs-extension It didn't work quite like I wished right "out of the box", but it wasn't too hard to hack it to behave more according to my wishes. Three cheers for open source software!
- ams6110 12y ago
  notmuchmail.org
e40 12y ago
I still use MH-E + nmh in Emacs on Linux, and I had phantasies of using it with IMAP and the GNU version of nmh, but I've never really seen someone say it works. Anyone?
- jfb 12y ago
  I don't think mh semantics could map to an IMAP server at all. I miss mh, but I switched to mu and isync, and it works OK.
  - nextos 12y ago
    I love mu as a mutt backend. The contact search is brilliant for address completion. However, it seems to lack thread reconstruction abilities like notmuch? Notmuch, on the other hand, lacks contact search. This is a bit silly, given that both are frontends to xapian.
    - mjn 12y ago
      Recent versions of mu do have some thread-reconstruction support. On the command line, you can use the --include-related parameter to 'mu find' to return whole threads when any message in the thread matches the search (rather than returning only the matching message). The mu4e emacs frontend also uses that in various ways.
      - nextos 12y ago
        Thanks, I didn't know. mu seems very well thought. How would you compare the current implementation to that of notmuch?
        mjn 12y ago
        I've only been using mu for about a week, so I'm not any kind of expert. On the other hand I did just spend a bunch of time reading about both mu and notmuch to try to pick one (and picked mu), so I can list some of what I came across, since it's pretty fresh in my mind. The main difference is in data models: mu uses Maildirs for message filing, while notmuch uses the Xapian db for message tagging. mu uses a traditional file-into-folders paradigm, where the folders are on-disk Maildir folders. You file messages by moving them. notmuch on the other hand uses a Gmail-style message-tags paradigm, where tags are stored in the Xapian db and the original files are treated as immutable. Messages on disk are never touched/moved; all changes to message state (even "deleting") are just tags in the db. IMO that makes notmuch more flexible: a tag can be anything, with user-defined tags and "built-in" tags like sender and subject being treated similarly. mu on the other hand treats the Maildir files as the canonical db, so its index includes only data from there: the message headers and content, the folder, etc. (no user-defined tags). An advantage of that is that it makes mu more interoperable, since other clients can read the Maildir structure without having to know about mu. It also makes mu feel a bit "safer" to me, since the Xapian db is purely a search index that can be regenerated at any time from the Maildir files with no data loss. On the other hand, notmuch's choice to never modify/delete/touch your original mail files is safer in a different way. Other differences: - mu is mainly developed by one developer (HN user djcb), while notmuch is more of a group effort. Some pros and cons to each there. - mu has a very nice proper manual. notmuch's documentation isn't bad, but it's not a nice proper manual. - mu collects a contact db by default. I believe there's also a solution for notmuch to do that though. - notmuch has a procmail-replacement story, https://github.com/teythoon/afew https://github.com/teythoon/afew, whereas many mu users still use procmail for initial message handling - I like mu4e, the emacs mail client that's developed together with mu. I haven't tried integrating either mu or notmuch with mutt or another client, though, so I don't know how they compare on that.
e12e 12y ago
So, I guess people really do use html mail now. I'm a little sad, but not surprised. I do find it a little bit ironic converting markdown (a format for structured plain text, allowing for easy quoting, in-line replies etc) to html. That aside, I can understand the frustration with web interfaces, and if committed to using gmail, why not have a nice interface for composing mails at least? My current pet peeve with google interfaces, are the text-editing boxes on g+ -- which are not text-boxes, and so doesn't work with "it's all text" -- and also breaks cut'n'paste for long sections of text. So I end up editing a text-file in vim, then copying section by section in ordert to post into g+ communities. Sigh. [1] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/ https://addons.mozilla.org/en-US/firefox/addon/its-all-text/
- nextos 12y ago
  I dislike that email, which predates the web, adopted html. And quite frustrated that many clients do not attach an equivalent plain text version of the email. I thought this would be a problem, but frankly piping in everything into w3m makes it surprisingly easy to stay plain text only if desired.
  - eddieroger 12y ago
    At the risk of being accused of being on your lawn, what do you dislike about email's adoption of HTML? I'm old enough to remember the walled garden "mail" of Prodigy and early AOL, and the advent of inter-network electronic mail, but I feel like HTML is a major contributing factor to taking email from something people didn't realize they had ("AOL gives me e-mail?") to something we can't live without now.
    - noise 12y ago
      Aside from spam, I mean marketing emails, what email do you send or receive that needs HTML?
      - whyenot 12y ago
        > that needs HTML? I think you are setting the bar a little too high. It seems to me like there is quite a bit of mail that benefits from HTML. Superscripts, subscripts, italics, bold and colored text (used in moderation), inline images (used in moderation) can be really useful when discussing concepts that aren't easily reduced to characters. Suppose your email would benefit from some mathematical formulas. You can do the old standby and drop into latex math mode, but the person on the other end of the email might not understand what you mean by \sum_{n=1}^k\,\frac{1}{n} \;=\; \ln k + \gamma + \varepsilon_k < \ln k + 1 much easier and clearer to use LaTeXiT or something similar and copy/paste in an inline image with the formula correctly formatted. Or, say you are a taxonomist. Italics in species names are not just a stylistic choice, they also convey additional meaning. For example in Epilobium ciliatum Raf. subsp. watsonii (Barbey) Hoch & P.H. Raven f. rosa the italics show what parts of the full scientific name refer to the species and what parts refer to authors or levels of taxonomic organization (subspecies and form). You can't do that with plain text (you could of course do it with markdown, though)... plain text is sufficient of course; but sometimes the additional bells and whistles of HTML really are useful.
HerrMonnezza 12y ago
I have been using "Gmail old compose"[1] together with "It's all text" / "Edit with Emacs" to achieve the same effect. With the old compose, there's no need to convert to/from HTML: email body is just text. [1]: http://home.oldcompose.com/ http://home.oldcompose.com/
- davidw 12y ago
  You can just use the settings to default to text emails, as I do.
  - HerrMonnezza 12y ago
    I can find no such option in my Gmail settings. Where is it?
neonkiwi 12y ago
This tool involves switching to Emacs to compose a message body, while doing all of your mail interactions with the web interface. Once composing is done, the content is sent to the browser. Optionally, you can write in markdown, processing that before the hand-off back to the browser. It would be possible to eliminate the back-and-forth jumping, just doing everything in Emacs, using the recently-announced Gmail API[1]. To the author, is this something you've considered doing? I'd use something like that. [1] https://developers.google.com/gmail/api/ https://developers.google.com/gmail/api/
- dang 12y ago
  > I'd use something like that. Me too. Sounds like a great side project for somebody.
- BruceConnor 12y ago
  This actually sounds nice and not too difficult. Thanks for pointing it out. Unfortunately, I barely have time to improve my existing packages anymore, let alone create new ones. So yes, it is something I've considered, but I wouldn't hold my breath if I were you.
baldfat 12y ago
Richard Stallman has just cried. I can't even think how mad he would be to know people use his Emacs to compose gmail messages.

68 points by lelf 12y ago

I recently started using mutt, connecting to GMail w/ IMAP. It's been working pretty well. I'm still really interested in a full mail client that supports all of gmail's features (labels, archiving, etc), and works well with Emacs.

nextos 12y ago
Gmail's implementation of IMAP is quite broken (and the XMPP/Jabber one too!). But you can achieve a local setup which rivals with Gmail by combining mutt and/or notmuch/mu and isync (mbsync). And it's quite possible to keep it sync'ed with Gmail, although there might be some rough edges. Personally, I don't thing tags are that useful if you have a fast and expressive local search engine like notmuch or mu (xapian-based), but YMMV.
rakoo 12y ago
I suggest you take a look at sup (http://supmua.org/ http://supmua.org/). Its goal is to transpose the gmail experience on your terminal. I've been working with the maildirroot branch [0] which mimics the IMAP installation of GMail, so you can use a standard OfflineIMAP to sync between your computer and GMail, and still use all the power of tagging/archiving/searching on your computer. Oh and it has a few niceties, the most important one to me being native support of gpg. Disclaimer: I'm one of the maintainers. [0] https://github.com/sup-heliotrope/sup/tree/maildir-root https://github.com/sup-heliotrope/sup/tree/maildir-root
- gcr 12y ago
  Once you've looked at sup, take a look at Notmuch (http://notmuchmail.org/ http://notmuchmail.org/), which separates the search/indexing of incoming messages from the mail composition from sending/receiving. As a spiritual sup successor, it has a few nice clients for the command line (bower?) and various editors (Emacs, maybe a vim client too)
- gcr 12y ago
  Once you've looked at sup, take a look at Notmuch (http://notmuchmail.org/ http://notmuchmail.org/), which separates the search/indexing of incoming messages from the mail composition from sending/receiving. As a spiritual sup successor, it has a few nice clients for the command line (bower?) and various editors (Emacs, maybe a vim client too)
stevenrace 12y ago
I've been using 'Mu4e' for the past few years and recommend it: http://www.djcbsoftware.nl/code/mu/mu4e.html http://www.djcbsoftware.nl/code/mu/mu4e.html
- michaelsbradley 12y ago
  mu4e-maildirs-extension is also quite handy: https://github.com/agpchil/mu4e-maildirs-extension https://github.com/agpchil/mu4e-maildirs-extension It didn't work quite like I wished right "out of the box", but it wasn't too hard to hack it to behave more according to my wishes. Three cheers for open source software!
ams6110 12y ago
notmuchmail.org

e40 12y ago

I still use MH-E + nmh in Emacs on Linux, and I had phantasies of using it with IMAP and the GNU version of nmh, but I've never really seen someone say it works. Anyone?

jfb 12y ago
I don't think mh semantics could map to an IMAP server at all. I miss mh, but I switched to mu and isync, and it works OK.
- nextos 12y ago
  I love mu as a mutt backend. The contact search is brilliant for address completion. However, it seems to lack thread reconstruction abilities like notmuch? Notmuch, on the other hand, lacks contact search. This is a bit silly, given that both are frontends to xapian.
  - mjn 12y ago
    Recent versions of mu do have some thread-reconstruction support. On the command line, you can use the --include-related parameter to 'mu find' to return whole threads when any message in the thread matches the search (rather than returning only the matching message). The mu4e emacs frontend also uses that in various ways.
    - nextos 12y ago
      Thanks, I didn't know. mu seems very well thought. How would you compare the current implementation to that of notmuch?
      - mjn 12y ago
        I've only been using mu for about a week, so I'm not any kind of expert. On the other hand I did just spend a bunch of time reading about both mu and notmuch to try to pick one (and picked mu), so I can list some of what I came across, since it's pretty fresh in my mind. The main difference is in data models: mu uses Maildirs for message filing, while notmuch uses the Xapian db for message tagging. mu uses a traditional file-into-folders paradigm, where the folders are on-disk Maildir folders. You file messages by moving them. notmuch on the other hand uses a Gmail-style message-tags paradigm, where tags are stored in the Xapian db and the original files are treated as immutable. Messages on disk are never touched/moved; all changes to message state (even "deleting") are just tags in the db. IMO that makes notmuch more flexible: a tag can be anything, with user-defined tags and "built-in" tags like sender and subject being treated similarly. mu on the other hand treats the Maildir files as the canonical db, so its index includes only data from there: the message headers and content, the folder, etc. (no user-defined tags). An advantage of that is that it makes mu more interoperable, since other clients can read the Maildir structure without having to know about mu. It also makes mu feel a bit "safer" to me, since the Xapian db is purely a search index that can be regenerated at any time from the Maildir files with no data loss. On the other hand, notmuch's choice to never modify/delete/touch your original mail files is safer in a different way. Other differences: - mu is mainly developed by one developer (HN user djcb), while notmuch is more of a group effort. Some pros and cons to each there. - mu has a very nice proper manual. notmuch's documentation isn't bad, but it's not a nice proper manual. - mu collects a contact db by default. I believe there's also a solution for notmuch to do that though. - notmuch has a procmail-replacement story, https://github.com/teythoon/afew https://github.com/teythoon/afew, whereas many mu users still use procmail for initial message handling - I like mu4e, the emacs mail client that's developed together with mu. I haven't tried integrating either mu or notmuch with mutt or another client, though, so I don't know how they compare on that.

e12e 12y ago

So, I guess people really do use html mail now. I'm a little sad, but not surprised. I do find it a little bit ironic converting markdown (a format for structured plain text, allowing for easy quoting, in-line replies etc) to html. That aside, I can understand the frustration with web interfaces, and if committed to using gmail, why not have a nice interface for composing mails at least? My current pet peeve with google interfaces, are the text-editing boxes on g+ -- which are not text-boxes, and so doesn't work with "it's all text" -- and also breaks cut'n'paste for long sections of text. So I end up editing a text-file in vim, then copying section by section in ordert to post into g+ communities. Sigh. [1] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/ https://addons.mozilla.org/en-US/firefox/addon/its-all-text/

nextos 12y ago
I dislike that email, which predates the web, adopted html. And quite frustrated that many clients do not attach an equivalent plain text version of the email. I thought this would be a problem, but frankly piping in everything into w3m makes it surprisingly easy to stay plain text only if desired.
- eddieroger 12y ago
  At the risk of being accused of being on your lawn, what do you dislike about email's adoption of HTML? I'm old enough to remember the walled garden "mail" of Prodigy and early AOL, and the advent of inter-network electronic mail, but I feel like HTML is a major contributing factor to taking email from something people didn't realize they had ("AOL gives me e-mail?") to something we can't live without now.
  - noise 12y ago
    Aside from spam, I mean marketing emails, what email do you send or receive that needs HTML?
    - whyenot 12y ago
      > that needs HTML? I think you are setting the bar a little too high. It seems to me like there is quite a bit of mail that benefits from HTML. Superscripts, subscripts, italics, bold and colored text (used in moderation), inline images (used in moderation) can be really useful when discussing concepts that aren't easily reduced to characters. Suppose your email would benefit from some mathematical formulas. You can do the old standby and drop into latex math mode, but the person on the other end of the email might not understand what you mean by \sum_{n=1}^k\,\frac{1}{n} \;=\; \ln k + \gamma + \varepsilon_k < \ln k + 1 much easier and clearer to use LaTeXiT or something similar and copy/paste in an inline image with the formula correctly formatted. Or, say you are a taxonomist. Italics in species names are not just a stylistic choice, they also convey additional meaning. For example in Epilobium ciliatum Raf. subsp. watsonii (Barbey) Hoch & P.H. Raven f. rosa the italics show what parts of the full scientific name refer to the species and what parts refer to authors or levels of taxonomic organization (subspecies and form). You can't do that with plain text (you could of course do it with markdown, though)... plain text is sufficient of course; but sometimes the additional bells and whistles of HTML really are useful.

HerrMonnezza 12y ago

I have been using "Gmail old compose"[1] together with "It's all text" / "Edit with Emacs" to achieve the same effect. With the old compose, there's no need to convert to/from HTML: email body is just text. [1]: http://home.oldcompose.com/ http://home.oldcompose.com/

davidw 12y ago
You can just use the settings to default to text emails, as I do.
- HerrMonnezza 12y ago
  I can find no such option in my Gmail settings. Where is it?

neonkiwi 12y ago

This tool involves switching to Emacs to compose a message body, while doing all of your mail interactions with the web interface. Once composing is done, the content is sent to the browser. Optionally, you can write in markdown, processing that before the hand-off back to the browser. It would be possible to eliminate the back-and-forth jumping, just doing everything in Emacs, using the recently-announced Gmail API[1]. To the author, is this something you've considered doing? I'd use something like that. [1] https://developers.google.com/gmail/api/ https://developers.google.com/gmail/api/

dang 12y ago
> I'd use something like that. Me too. Sounds like a great side project for somebody.
BruceConnor 12y ago
This actually sounds nice and not too difficult. Thanks for pointing it out. Unfortunately, I barely have time to improve my existing packages anymore, let alone create new ones. So yes, it is something I've considered, but I wouldn't hold my breath if I were you.

baldfat 12y ago

Richard Stallman has just cried. I can't even think how mad he would be to know people use his Emacs to compose gmail messages.