3 ms·

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

by 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.
nextos 12y ago
If you're looking for a fast IMAP syncing tool, isync (mbync) is great. I used offlineimap for many years, but it was buggy, slow and heavy. It's a tiny C utility written by the mutt creator, Theodore Tso and others, so it's very good as expected.
- jfb 12y ago
  It has a peculiarly complicated configuration, but it has been 100% bulletproof for me.
  - nextos 12y ago
    Just curious, what did you find complicated?
    - jfb 12y ago
      That's a good question. It's one of those things that I remember being complicated, but when I look over my configuration, it seems pretty damn straightforward. I guess the fact that Channels and Groups share a namespace irritated me? Anyway. It's a great piece of invisible, blue-collar software.
- hobarrera 12y ago
  The lack of imap IDLE is a killer for me. I don't want to poll the server all the time, but I want to be notified of email ASAP. Offlineimap also breaks with imap IDLE, regrettably.

by 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.

nextos 12y ago

If you're looking for a fast IMAP syncing tool, isync (mbync) is great. I used offlineimap for many years, but it was buggy, slow and heavy. It's a tiny C utility written by the mutt creator, Theodore Tso and others, so it's very good as expected.

jfb 12y ago
It has a peculiarly complicated configuration, but it has been 100% bulletproof for me.
- nextos 12y ago
  Just curious, what did you find complicated?
  - jfb 12y ago
    That's a good question. It's one of those things that I remember being complicated, but when I look over my configuration, it seems pretty damn straightforward. I guess the fact that Channels and Groups share a namespace irritated me? Anyway. It's a great piece of invisible, blue-collar software.
hobarrera 12y ago
The lack of imap IDLE is a killer for me. I don't want to poll the server all the time, but I want to be notified of email ASAP. Offlineimap also breaks with imap IDLE, regrettably.