I really hope people are not that close-minded, seriously...
By the way, from the wiki:
It's a cool name. What does it mean and how should I pronounce that word?
It's a Czech word which means "triple". The meaning is an inside joke related to a Czech pseudo-word, blésmrt. The whole story is inspired by Mutt's "all e-mail clients suck, this one just sucks less". The real pronounciation is rather hard for English speakers, so you can stick with a Spanish-like style.
In Italian, "troia" means "whore", as well as the ancient city of Troy. Italian uses "ina" or "etta" as diminuitive suffixes, rather than the Spanish "ita", but still... I don't know that I'd want to be discussing it at work.
And we (italian) speak about the city of Troy without any shame because has a completely different meaning, so I don't see any problem in speaking about Trojita at work (which is also a nonexistent word in italian, opposite to the translation of Troy)
I don't think it's about being close-minded, if you name a word suggestively close to something negative then you'll get negative associations with it. It's not rocket science.
(Obligatory) Those who make a thing (not to mention give it away for free, in this case) can name it whatever they like. If there are people out there not using the GIMP because of its awesome name, well... That's their loss, but long live self-expression.
The idea isn't that people can't name things as they like. It's that they should consider the name if they want wide adoption (See RMS and $POSIXLY_CORRECT-vs-$POSIX_ME_HARDER).
Perhaps you might clarify your reference. Based on my understanding, RMS is describing the difficulty addressing machine-compatibility between different implementations of a supposedly-similar interface/protocol/specification. The name of a wholly new application doesn't have similar obligations. A person might think about the implications of the name socially, but is still ultimately free to ignore them. Even RMS notes "I would guess that very very few users set POSIXLY_CORRECT [vy8vWJlco: the more socially-congenial name]. If users don't like these decisions (or any others we make), they are free to change them."
( http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_int... ) It's open source, so someone could fork it with a new identity.
Maybe POSIXLY_CORRECT was probably a bad example as it's not necessarily a heavily used option. On the other hand, no one is crying 'censorship' (or stifling of artistic creativity) because RMS didn't name it POSIX_ME_HARDER.
| It's open source, so someone could fork it
| with a new identity.
We've seen this happen before (e.g. OpenOffice/LibreOffice, Jenkins/Hudson). Just because it's an option doesn't mean that people can't complain about the decisions that cause these splits.
And yet, noone's forked the GIMP just to change it's name. ("A rose by any other name would smell as sweet"...) Those other examples of forks you gave are also examples where a quorum of the major contributors chose a different path; whereas, in this case, the major contributors chose the name.
I don't see GPG/PGP integration. I have been looking for a lightweight, multi-platform offline capable IMAP client with good GPG/PGP encryption for awhile now, and nothing seems to quite fit the bill.
I'm also looking for something similar for OSX/Linux. I'd love to move my "life" away from services like gmail (not that I have anything against it, just don't like having all my data that far away from me).
Have you tried Claws mail? :http://www.claws-mail.org/ It has support for gpg (inline and mime) and is multiplatform, maybe you have done and you don't like it
Last time I tried Claws mail (which was years ago) the interface left something to be desired. It was too cluttered, and difficult to use on a small (1024x768) screen.
Unfortunately it's apparently very difficult to keep up with Apple Mail. There's not a public api for the project to hook into, so GPG support always lags new releases of Mail.app by quite a while. 10.8 still does not have a public release of GPGMail.
I can imagine there are many, in day-to-day use I find Thunderbird to be one of the worst e-mail clients I've ever used. Slow, unstable, makes simple things hard (try to configure an LDAP address book) and many basic features simply don't work (IMAP search for example).
In short, Trojitá is a pure IMAP client, written from the ground up to work well over IMAP with no support for any other kind of mailbox. It synchronizes stuff lazily, and (something that's close to my heart), is extremely aggressive about pipelining. I haven't read the source code in detail yet, so I haven't checked how the low level code is implemented, I'll let you know when I learn more. For now, if you're interested, I warmly recommend reading chapters 1 through 3 of Jan's thesis."
Speed. I sometimes try it with my IMAP server (dovecot, around 15GB of email) and it's blazing fast to browse the folders.
It also is quite a light feather (~20 MB of memory).
Claws-email is another very fast and very light email client.
It does stay responsive while scanning a large (200k) [Gmail]/All mail folder, but apparently it has a single connection to Gmail because no other folders or messages can be obtained during the download. After about five minutes it has a basic list of headers (but not the subjects) and there seems to be more concurrency. It would be better if it chunked the large scan and allowed other operations to complete (assuming progressive scanning is possible).
Interesting, because the only slow action when opening mailboxes is fetching and applying the thread index, and gmail does not support that particular feature. Which means I don't really know how it can take a "few minutes" on GMail -- all it does it simply fetching the UIDs...
I wanted to know the same, so I looked it up on Wikipedia:
Formerly known as Sylpheed-Claws, it [Claws] started in April 2001 as the development version of Sylpheed, where new features could be tested and debugged, but evolved enough to now be a completely separate program. It forked completely from Sylpheed in August 2005.
Good IMAP clients is something I always look out for. Be they command line, web based, or GUI clients. Most of the ones I have tried have had performance problems so I like they have it as one of their core goals.
Mulberry [1] used to be my gold standard of IMAP clients. It has one of the most complete IMAP implementations I've ever seen. Unfortunately the company that made it went out of business in 2005, but a little while later it came back and then was open sourced.
There doesn't seem to be a lot of activity on the open source project and I eventually switched to Thunderbird (which only gets better, it seems). But I do miss many parts of Mulberry. It was stable, fast, and detailed.
Mulberry was my mail app of choice back circa 1998. At the time, it was verifiably the most complete implementation of IMAP available. It supported server-side searching, server-side copying, shared mailboxes, and I believe partial fetch. All features that no other IMAP client supported at the time. Some of these feature were even difficult to find in server implementations.
It was always my understanding that Pine, from the University of Washington, also home to the inventor of IMAP, was one of the most "correct" IMAP clients. It's pretty minimal feature-wise, though.
I took a quick look and still prefer Thunderbird. Over the years tb has matured enough that it's solid and reliable. All I want from my work email client. For personal stuff, I'd never consider a client, other than the browser.
In the past decade or so (basically since it came out) I've tried Thunderbird 3 times. Each time it lost some of my data. Granted only the first 2 times was I using POP; with IMAP having an e-mail client that completely corrupts and is unable to recover the local mailbox isn't nearly as big a deal, but it still makes me not want to use it.
Even Evolution, which had a history of crashing if I looked at it funny, and seemed to be implemented as a loosely associated group of processes, any one of which could decide to monopolize the CPU and/or disk IO at any point never lost e-mail messages for me.
Did you get it running? I compiled on debian stable and the app runs, but segfaults as soon as i try to read an email. There is really a need for an improved imap client, thunderbird is good but innovation feels like it got stuck.
Off topic: Can anyone recommend a good command-line mail client. I'm used mutt quite a bit. Wondering if there are any more out there that are at least as good as mutt.
I always go back to mutt. It does one thing, read email, and it does it well.
The key is to set it up appropriately. Don't use mutt for downloading your email, especially if you wanna deal with IMAP. Use isync (mbsync) for that purpose (I used to use offlineimap, but it's buggy and not very fast).
There's also notmuch, which I use for indexing my email. It also contains a pretty good email reader.
My favourite bug was when it was blocking on wanting a password, but wasn't accepting input. I had to kill it externally because it wasn't accepting C-\ or C-c.
Same here, but, if you use it with Gmail, let me recommend Abdó Roig-Maranges' fork of offlineimap, which implements labels[1][2]! That way you can sync only [Gmail].All Mail and all the other info (such as /Inbox, /Sent and any other custom labels) come as X-Keywords in the header (no duplicates, and no lost metadata)[3]. And mu4e supports all this[4]!
[3] [Gmail].Trash and [Gmail].Drafts are also real folders, not just labels. You should sync them too. [Gmail].Sent Mail is just a saved search for /Sent labels. mu4e asks for a "sent" folder but, since you should (setq mu4e-sent-messages-behavior 'delete) anyway with Gmail, it becomes a dummy folder locally, and all is well.
I've bookmarked your comment. I'm gonna be forced to move back to commandline when gmail finally foists the new compose on me (fuckers[1]).
[1] Some of us want to, you know, use email for longer messages than a tweet. It's hard to do that when PgUp/PgDn are so janky. And don't even get me started on S-PgUp and S-PgDn.
I like notmuch with the Emacs notmuch client, because it'll work fine when I only have a terminal available, but when I run Emacs+X11, it'll also display images inline and has some decent mouse support.
It's fast, but not conversations based; there's no threading at all that I can see, except a "replied" icon that isn't even an active link. It's a shame because conversations (unlike labels) don't require any protocol extension, thunderbird conversations work on any server.
About labels, I believe they are sort of in the IMAP spec as keywords or something like that, so if Gmail is being nice, they should work.
About conversations, I read that Gmail does some client-side sorcery with In-Reply-To headers for that, so if this client does the same, it should work.
(Side note: It's been a few years since I looked through the specs and maybe I missed something)
IMAP flags are sadly severely lacking in what they can represent. The character set isn't even enough for unmodified UTF-7 (Punycode could work, but only for one-word tags) which renders them useless for user-chosen labels so few mail clients actually bother supporting them in that way. Thunderbird uses \label1 through \label5 but the names that are displayed in the UI are stored on each computer separately so you'd have to set up the labels you use on each machine (which kinda defies the purpose of storing that on the server). And short of using a »label configuration mail« on the server I don't see an easy way of supporting them completely server-side.
I'd love to completely forego folders and use tags/labels/flags/whatever they're called exclusively but last I looked IMAP wasn't able to support that.
You can determine labels, it's just more work. I wrote a script a while back that used IMAP to just generate a list of message-ids and the labels associated with each one. I iterated over all messages in all folders to build the associations. It might be possible to query for a single message-id in all folders, to get a list of labels to, but you would need to know the message-id ahead of time.
Nobody builds the Windows binaries regularly. Last time I did so, it worked without any problem. If you'd like to help maintain the Windows port, I'll be happy to have you on board.
