Mutt Fork Adds Features From Notmuch 93
Karel Zak started a fork of Mutt back in January to integrate features the upstream authors deemed too radical, and today released the first status update. So far implemented is native notmuch support (inspired by Sup) which adds fast search, tagging, and virtual folders from notmuch queries. Unlike the current hackish solutions, all of these are available as native mutt commands and can be used in your muttrc. Additionally, patches from Debian and other distributions will be integrated. Source is over at Github, and a few screenshots are on their wiki.
uhh... does anyone still use mutt? (Score:1)
I moved from pine --> mutt --> any modern mail client.
Re: (Score:3)
I still prefer text e-mail readers (Mutt these days). I don't need fancy GUI, graphics, formatting, etc. Same for IRC and IM clients. Tin, nzbget, wget, aria2c, etc. Yes, I am old school so get off my lawn. Also, they are handy for slow and unstable Internet connections like dial-up for remote connections. Oh and more secured!
Re: (Score:2)
Re: (Score:2)
Ditto. I do too. I forgot to mention that I rarely use text web browsers like eLinks. Maybe for very quick check when I don't care for images, formattings, layouts, etc.
Re: (Score:1)
Re: (Score:2)
Hehe, yeah that too. Also, to check suspicious web sites. Old school stuff are still useful! :)
Re: (Score:3)
I actually just switched from Apple Mail back to Mutt, because a combination of Mail and an Exchange server ate a huge chunk of my email archive. I'm not sure if I'm really more productive, but I feel a lot more comfortable knowing I have a degree of control of what's going on, and that stuff is being stored in an open format (Mail switched from Maildir to something weirder a while back). Losing a chunk of my email archive was pretty traumatic.
The main thing holding me back was a decent email search feature
Re: (Score:1)
There aren't many email programs on Linux/Unix. Among those few, only three I find acceptable:
- Kmail: but it requires that huge, horrible KDE bloat and kitchen sink. So no.
- Claws: considerably better than Sylpheed. Neither really work without a mouse. I mean, I have Claws just in case (to view HTML mail, mutt sucks at that) and I hate it because I keep having to reach for the mouse to do many things. I really can't do them with the keyboard. And it can use Vim as the editor for composing mail, but in such
Re: (Score:1)
Me.
Re: (Score:1)
I used to use mutt. I had it all pimped out to support bunches of lists and a few dozen email addresses and do cool things on the results of procmail filters and so on. While everyone else was fighting with Outlook or extolling the virtues of Eudora I was the only person I knew who could search nearly 10 years of email from any computer, including my (barely) smartphone.
But then my coding chops ossified, I got annoyed bouncing mail to another POP box to deal with attachments or images, and I plain got tired
Re: (Score:2)
I often need to email someone a file that's on my desktop, so I SSH in from my cell phone, and e-mail it using mutt. Beats using VNC+"some modern client".
It also helps when I break thunderbird for some reason, or when I'm on a PC that's not my own (over SSH, again), since I don't have any webmail configure (yet).
Who uses Mutt? (Score:1)
No, seriously. Who here is using it? What's it do for you that made you choose it, or this fork?
[Disclaimer: Claws-mail. It's fast, and I'm lazy.]
Re: (Score:1)
Most "modern" e-mail clients choke on a decently-sized archives.
GMail sucks for anything other than person-to-person conversations (ie: it sucks for mailing lists or anything threaded). It's also no good for talking about code (no fixed-width support, no plain-text email support at all).
Of course, I hate mutt, too.
Re: (Score:2)
GMail isn't an email client.. it can be used with one though, and then it's just regular IMAP (+ Google's Heavy Breathing :P)
Re:Who uses Mutt? (Score:5, Insightful)
* it's fast
* it *doesn't* run javascript or display images
* it doesn't try to display messages in some ghastly proportional font.
* it doesn't fuck with my mailboxes or try to move/import them into it's own format.
* it's a mail reader. it doesn't pretend to be a mail sorter/filter as well, i leave that to procmail.
* excellent searching and tagging operations.
* regexp support for searching and tagging.
* it works identically for me whether i'm physically in front of the machine or connected via ssh.
* in combination with screen, I don't even have to restart mutt when i login, i just connect to the screen session.
* i get multi-folder support by running 20 or so mutts in the background, each one with a different mailbox open. switch using ^Z and shell fg command.
* no crappy built-in editor.
* 'set edit_headers' in .muttrc lets me edit the ALL of the headers as well as the body - convenient for trimming the To:/CC: list, or deleting unwanted In-Reply-To or References headers (i.e. lazy group reply for a new msg without hijacking an existing thread).
* lots of other benefits, too numerous to mention.
Re: (Score:2)
Do share, by all means! O_O
Re: (Score:2)
Hear, hear.
Its being a real console app is great.
Re:Who uses Mutt? (Score:5, Interesting)
Mutt also:
- plays nice with tools like fetchmail, procmail and grepmail
- lets me use MY editor-of-choice (vi, of course)
- runs beautifully over low-bandwidth connections
- does not fill up my screen with pretty-but-useless crap
- allows me to define key bindings and macros to my taste
- I can use color-coding (when on a color-supporting tty) to highlight things like URLs, email addresses, etc.
- it does NOT parse HTML (HTML email is used exclusively by two groups of people: (1) spammers and (2) ignorant newbies who don't know any better.)
- it handles MIME sanely -- and has a nifty feature that lets you delete individual MIME attachments, which is very handy on occasion. Adding attachments is also quite easy.
- it supports multiple mailbox formats, it supports POP and IMAP
- it's highly resistant to attacks by design AND implementation
And so on.
It does support HTML (Score:1)
'mutt' is the best way to read mail in my opinion. I use it both at home (local folders) and work (IMAP).
Re: (Score:3)
* it doesn't try to display messages in some ghastly proportional font.
I just don't understand this one. Proportionally spaced fonts are more readable -- that's why they're used in just about everything published in print and, yes, pretty much the entire Web. HTML is everywhere these days. There are no longer any network bandwidth constraints or storage space constraints that make sending HTML mail inefficient. Why do some people still get so fired up about keeping email in plain, unformatted text in a typewriter font? At this point, it seems like some sort of "geek cred" thin
Re: (Score:3)
it's about functionality, not fashion:
1. plain-text is readable by anything, and is easily grepped, piped, manipulated by standard tools, and otherwise *used*.
2. log file lines, programs, and tabulated data are all unreadable in proportional font.
3. 80 columns (72-78 is typical) is the standard for email.
the *only* valid excuse for including longer lines is when copy-pasting log lines or code fragments or similar. for discussion, reformat paragraphs with par (or fmt if you don't have par installed)
BTW, not
Re: (Score:2)
Proportional spaced fonts does not require HTML. Plaintext can be rendered in monospace or proportional space and even the command line works fine either way. The OP was bitching about a "ghastly proportional font". The GP's point about proportional fonts being more legible, and the ubiquity of HTML are two different points.
Re: (Score:2)
I *am* the OP, and the reasons I cited above are most of why i think proportional fonts are ghastly for email.
BTW, proportional vs monospace is not what defines whether a font is ugly or legible of pleasant to read. There are ugly and eye-straining fonts in both proportional and non-proportional styles. There are also pleasant, legible, and eminently readable fonts in both.
some kinds of text, however, pretty much require a NP font to be rendered legibly. source code and log files for example. terminal wi
Re: (Score:2)
damn. html ate my <.
that should have been "< 80 columns".
Re: (Score:2)
Come on, man, be serious. Are you a tech guy? For real?
1. plain-text is readable by anything, and is easily grepped, piped, manipulated by standard tools, and otherwise *used*.
And HTML isn't? It's practically XML. XHTML is XML. If you can't grep and pipe that shit, what are you good for, man?
2. log file lines, programs, and tabulated data are all unreadable in proportional font.
So I'll use a <pre> tag, for fuck's sake. Every email reader I've ever seen supports it.
3. 80 columns (72-78 is typical) is the standard for email.
On what? Your WYSE terminal? Besides, if it's a proportionally spaced font, your measurement has no meaning.
3. 80 columns (72-78 is typical) is the standard for email.
Again, according to whom? Your CASIO Usenet watch?
You're just being silly, honestly.
Re: (Score:2)
no, you're just being stupid and short-sighted.
the point of email is communication. - communication with all readers, not just those who happen to be using the same software as you.
HTML in email is fucked up and stupid for the same reason that MS Word documents in email are fucked up and stupid, or why writing your email in LaTeX would also be fucked up and stupid.
plain text works with all mail clients. HTML doesn't. XML doesn't. LaTeX doesn't.
and when morons of your ilk
Re: (Score:2)
What's old is new again.
Good old 80-columns is useful for the small form-factor devices that are popular today (ultrasmall notebooks, tablets, smartphones).
Re: (Score:2)
Honestly, I find that sometimes I want fewer columns. That's why I'm pro-long lines now. Let the client decide how to wrap your lines. My phone either won't display 80 columns, or it displays them in a tiny, tiny font.
With length-80 lines on a length <80 screen,
you get
jaggies which are even harder to read.
EVERY
decent mail client (console-included) knows
how to
wrap long lines, but none of them know how
to join
shorter lines in a way that is guaranteed to
maintain
paragraph breaks that the original author
intend
Re: (Score:2)
BS.
There is no markup needed to use proportional width fonts. You get that for free with 0 extra effort in any system. For the few times you need a fixed-width font, any WYSIWYG email client makes it trivial to format a block of text monospaced.
Re: (Score:2)
Proportional fonts mangle the formatting of things like tab-separated tables, and any competent 'nix person deals with those all day long. They thus cause the loss of semantic content, because the alignment of the fields in those tables is important. Moreover, the display choice of type for those of us who work remotely is a pseudo tty, which is unlikely to support them. As someone trained in typography, I recognize that proportional fonts have a slig
Re: (Score:2)
Proportional fonts may be generally 'prettier' perhaps but they are certainly not more readable. They destroy plain text formatting which is the quickest, simplest, and most efficient way to format text that isnt actually intended to be printed out or prettified (i.e. email, code, settings files.) Destroying all my formatting and then claiming to have made my texty more readable isnt going to fly.
proportion vs. monospace fonts (Score:2)
Proportionally-spaced fonts are modestly more readable than monospace, for prose text.
Monospaced fonts allow for column-based formatting of tables, ASCII-art diagrams (networking, etc.), programmatic output, etc., which makes for a greatest common denominator balance between both readability and flexibility. For technical uses (programming, systems/network admin), monospace wins hands-down. It's also very easy to write simple programs / shell scripts to output data in fixed-length columns, which again,
Re: (Score:2)
No kidding. As far as I can tell, it is also the only mail reader (at least out of those that I tried) that gets threding and sorting right.
Re: (Score:2)
* i get multi-folder support by running 20 or so mutts in the background, each one with a different mailbox open. switch using ^Z and shell fg command.
I'm not sure I understand why this is necessary or useful...
I use Mutt all the time. I have it configured to know about all the sub-folders/sub-mailboxes that procmail sorts into. With the press of a key in Mutt I can either type in the name of a folder to switch to (with tab completion) or press ? to use Mutt's internal file/directory browser.
I also don't have to manually tell Mutt what folders I have. Because you can set variables in muttrc to the output of a shell command, I have it set up to use find
Re: (Score:2)
It's not necessary, but it is useful. and yes, a different problem.
changing folders in mutt is a PITA. You have to close your current folder when you open the new one. To close it, you lose all your current context in that folder - you have to save or abandon any changes (e.g. deletions) you've made, and lose the tag status of any tagged messages. and similar small annoyances. and if they're large folders, they can take several seconds to save-and-close, and then more time to open the new one. even on
Multiple mutt sessions vs. switching folders (Score:3)
When you've got many or large folders, the switching time can be substantial.
Systems admin, with various alerts and notifications getting filtered to various places. Opening a folder with ~10k messages takes a few seconds, ~100k really starts to bog down. Once I'm in the folder, filtering, tagging, and other actions are really quick. Getting there is slow.
My compromise: screen with several mutt buffers open, primary ones are my inbox and other hot folders, others I'll switch between less-frequently
Re: (Score:2)
I actually switched from mutt to the notmuch interface in Emacs last year. I had planned to drop mutt altogether for 2 years prior to that.
Mutt is fairly good, but it just became ridiculously stagnant. Long standing requests were not addressed.
Does it still not allow you to Fcc to more than one file? If so: Pathetic.
I forget what my second major gripe against it was...
Of course, notmuch in Emacs has its own warts as well, but somehow I think I can fix them using Elisp more easily than fixing mutt using C.
In
Re: (Score:1)
I do as well as bunch of people who likes software that doesn't suck that much.
Re:Who uses Mutt? (Score:5, Informative)
I use Mutt. I've also used various incarnations of Mozilla Mail, KMail, Apple Mail, Microsoft Outlook, a few webmail systems, and done test runs with a few mail clients I forgot the names of.
In the end, I came back to Mutt. It's the mail client I'm most productive with. I customized it to work the way I want. I'm used to it.
I think Mutt's strengths are:
* Customizable. Mutt is fairly easy to customize, and the customization goes a long way. Define things you want to do in terms of s-lang functions or shell commands, bind a key to them, and boom, now you can do everything you often do with a single keystroke.
* Good support for multiple e-mail addresses. I have a single account that I use with multiple e-mail addresses. Mutt makes this easy. A number of other mail clients I have used make this tedious. Some do not support it at all.
* Works in the terminal. I like to work in the terminal. I know many people don't. But if you do, this is an advantage.
* It works. I never have problems with it. I wish the same was true of all mail clients I've used.
Weaknesses:
* Slow on large maildirs. I have folders with tens of thousands of messages. These take long to open. Part of this is "many files that need to be statted, and stat is slow", but part of it is implementation choice. Some mail clients are way faster at this.
* Slow on IMAP folders. It looks like Mutt fetches messages or message headers one by one for each message. My mail server is over 100ms away. This makes things slow. My fault? Mutt's fault? Anyway, it's a disadvantage. Some mail clients do better.
* Wastes screen real-estate. I like that Mutt works in the terminal. But it wastes space. Graphic-mode mail clients can fit more information in the same space than Mutt does.
Re:Who uses Mutt? (Score:5, Informative)
Have you set your index_format? And have you tried pager_index_lines to split the screen into index + message view?
Re: (Score:2)
On the maildir issue, it gets a lot better with a (small) SSD. I have my maildir on a RAID1, formed from one 30GB SSD and a partition from a HDD (set to "write mostly"). That solves the issue for me (> 2500 Emails in inbox at the moment).
Re:Who uses Mutt? (Score:4, Insightful)
Who's using Mutt? Any serious email user who doesn't top-post. The crowds went to ICQ in late 90s, GaduGadu/MSN/... in 2000s, some Facebook junk in 2010s. Business users keep sending mails with no subject that have no content except for a Word or Excel attachment -- or even worse, a .bmp file (although that's typically embedded in a .docx nowadays).
I personally have Thunderbird/Icedove on all the time, used as nothing else but a glorified biff and a tool to view attachments sent by the business folk from the previous sentence. Any actual mails go via mutt ("actual mail" defined as something consisting of text rather than an almost bare attachment).
GUI clients tend to choke horribly on any mailing lists, or any structured conversations.
Re:Who uses Mutt? (Score:5, Interesting)
I once proposed that anyone who top-posted or full-quoted should lose a finger every time they did so. I believe that the overall quailty of mail traffic, particularly on large mailing lists, would be markedly improved in short order.
Regrettably, the RFC didn't find traction within the IETF. Pity.
Re: (Score:2)
that's undoubtedly because you were too lenient on the top posters.
Re: (Score:2)
Fund it!
Re:Who uses Mutt? (Score:5, Funny)
"Any serious email user who doesn't top-post." I once proposed that anyone who top-posted or full-quoted should lose a finger every time they did so. I believe that the overall quailty of mail traffic, particularly on large mailing lists, would be markedly improved in short order. Regrettably, the RFC didn't find traction within the IETF. Pity.
Re: (Score:3)
people still use procmail in 2012 for the same reason they still use screwdrivers or hammers or other basic tools.
for the job that they do, there is nothing better.
maybe someday there'll be something that does mail filtering & sorting as well as procmail. and maybe someday there'll even be something that does a better job than procmail. when that day arrives i'll evaluate whether it provides enough of an improvement to be worth the effort of switching to it.
ps: you're the one who sounds like a 'luddit
Re: (Score:3)
name one.
it's not perfect, nothing is. but it's adequate.
or is that just your way of saying "it's too hard! waaah!"
mutt is "poorly featured". that's amusing...in the same way that a small child saying something fundamentally wrong but earnestly and sincerely believing it is amusing.
mutt is the full-featured email client. with many more features than c
Re: (Score:2)
Also, tell me how exactly can one make GMail's or $RANDOM_GUI_CLIENT's filtering trigger a rebuild and regressions tests when you get a commit announcement.
Or, how can you pre-fetch gpg keys for mails you receive.
Or, how can you add a References: header based on the mail's content (to get a semblance of threading for dokuwiki change notifications).
Or, how can you...
Re: (Score:2)
Doesn't sieve do the same job with a nicer and standard syntax?
Re: (Score:2)
Last time i looked, sieve couldn't pipe a message (header or body or both) into an external program. and it doesn't even support regexp matching by default.
For me, both are required....and regexp matching is what I would consider to be a base-level core feature required of any mail filtering software.
I just had another quick look at it and noticed that it also seems to be lacking:
* the ability to detect duplicate messages by Message-Id:
* the ability to clone an incoming message so that it ca
Re: (Score:2)
You're quite right actually.
I'm rather surprised by the lack of regex. I googled a bit, and there's a propused draft, but as you said; it should be a core feature.
Disallowing piping is due to it's nature; it's mean to be run on shared mails servers, by "users", not just power-users or techies.
The lack of ability to detect duplicate messages is logical, it's stateless and only passes messages over. It's not a mailbox organizer. procmail shouldn't be doing that either actually.
A huge advantage of learning si
Re: (Score:2)
since i run my own mail server with just a handful of users, i only have to care about "power-users" or "techies."
piping messages is essential - software that tells me, on my own server, "you can't be trusted to do that" is not likely to endear itself to me. and if it's
disallowed by sieve because of sieve's nature, that means sieve is not suitable for my needs.
procmail *should* be doing anything i want it to. including piping messages through formail for Message-ID dupe detection.
as i said before if one c
Re: (Score:2)
I may not have been clear; I didn't mean to imply that you should not be using procmail, I was just pointing out the differences with sieve and how it's targeted to a somewhat different audience.
Re: (Score:3)
Re: (Score:2)
then you're either an ignoramus, an arsehole, an idiot, or some combination of all three.
Re:Who uses Mutt? (Score:5, Insightful)
Re: (Score:3, Insightful)
Infinitely better support for identities (Score:4, Insightful)
Every other email client supports identities in the same clumsy fashion. Each and every identity must be individually configured in. That's fine when you four and they never change. It is nearly useless when you have 400 and add several new ones each week.
Mutt lets me define identities with regular expressions. I can set alternates=(.*@foo,example.com,.*@bar.example.com)
Now every user @foo.example.com and @bar.example.com will match as me, even ones I haven't thought up yet.
When sending a new message, I can type in whatever I want in the From: field. When the reply comes in, it is automatically recognized if it matches an established pattern. I haven't had to change my alternates in years even though I have added hundreds of identities.
Re: (Score:2)
Try virtual identity for thunderbird. [absorb.it] I've found it to do everything I need for handling the hundreds of identities I use with my domains.
Re: (Score:3)
I use it. I prefer software I can access through an SSH client (so I don't need any other special software on whatever machine I happen to be using). I used Pine for a while, but I got annoyed with the license issue that stopped Debian from shipping compiled binaries, and mutt handled threading better.
That was the reason for starting to use it. After that I've noticed a ton of details that are nice. It handles mailboxes with thousands of mails with acceptable speed. It lets me edit headers of outgoing mails
Re: (Score:1)
I use mutt,, primarily for four reasons:
1) It's character-cell/terminal, and I like that. (It'll pop up a browser if you need to view HTML, but that rarely is necessary.
2) It's very configurable, and does what I want.
3) I often SSH into my machine and POP my mail remotely (like, at work). maildir support is good, and it lets me do mail from anywhere I want.
4) Integrates well with VIM, and I use vim for almost everything.
"Modern mail clients" offer very little advantage for doing email, which is after all a
Re: (Score:2)
Have been using it for decades. Fast, lightweight, not susceptible to malware (unless you configure it stupidly), good GnuPG integration, good mailing-list support, tagging support, and, most importantly, fast to use over SSH. Seriously, these modern webbrowser-maskerading-as-MUAs are a lot lower in usability. Why some people need a GUI for everything is beyond me.
Re: (Score:1)
Same here. It's actually fun in mutt to see the clever ways the malware authors try to fake out the Window users of the world with encrypted javascript and other nonsense.
Re: (Score:2)
Indeed. Quite fascination on occasion.
Re: (Score:1)
I do. Email doesn't need a graphical application and the excessive resource usage of a GUI.
If I need to view any attachments, I can use a mailcap definition for each type that I want to access (and can update that on the fly if something surprises me).
And I'm contributing to the mutt-kz project as time permits to add the features that would make this sort of mail client all the more useful.
Re: (Score:1)
No, seriously. Who here is using it?
Me.
oblig. abbott and costello joke (Score:5, Funny)
"Whats in your new release?"
"Notmuch"
"That's what I'm asking, what did you add that's not in the original software?"
"Notmuch"
"Oh... well, did you improve on the performance?"
"No, that's still the same as Mutt"
"Still as slow as a dog?"
"No, it's at least as fast as Mutt"
Re:worth checking out? (Score:4, Informative)
yes.
if you're used to pine, it will take a day or two to get used to mutt's keybindings. it'll probably piss you off while you're learning them, because there are some subtly annoying differences.
after that, you'll be glad you did and you'll never look back.
mutt's searching and tagging features alone are worth the switch.
Re: (Score:2)
Yes, another former (al)pine user here. Header caching alone makes it worth it.
Re: (Score:3)
I'm a bit divided on whether I like (al)pine or mutt more.
alpine does local deliveries well, but defaults to creating external lock files and requiring world write access (instead of more sensible 3775 permissions), which opens up for denial of service attacks. And what it does when new mail arrives is attrocious - you pretty much have to exit and re-enter.
Mutt on the other hand, defaults to color, which is rather annoying, and can't do local delivery but depends on the availability of a sendmail compatibl
Re: (Score:1)
Mutt speaks SMTP now: http://www.mutt.org/doc/devel/manual.html#smtp [mutt.org]
Re: (Score:2)
Mutt speaks SMTP now
Yeah, and that's a good thing, but it doesn't do local delivery.
On multi-user systems, it's nice to be able to leave a message to other users, without depending on another mail delivery agent. Even on machines that don't have mail servers installed. When setting up linux boxes or VMs for people, I like to leave a message in their inbox. Sure, I know the mbox format well enough to do that with vi, or I can temporarily enable a mail server on the box. But local delivery is still a missed feature in mutt.
Re: (Score:2)
it's easy enough to write a monochrome .muttrc
you can probably find one on the net if you search.
mutt shouldn't do local delivery - or do you routinely misconfigure systems so that mailboxes are world-writable? or do you want mutt to be setuid root or setgid mail?
mutt's job is to be an MUA, not an MTA or MDA.
there are numerous light-weight MTAs
Re: (Score:2)
mutt shouldn't do local delivery - or do you routinely misconfigure systems so that mailboxes are world-writable?
Hell no. Removing o+w for /var/spool mail (or /var/mail) is about the first thing I do on systems, cause MOST distros seem to get this wrong.
or do you want mutt to be setuid root or setgid mail?
If mutt had been capable of local delivery, it should be setgid mail, definitely. Any MDA you use with mutt most certainly is either sgid mail or suid root.
The thing is to give /var/spool/mail sensible permissions., like 3775 root:mail. I'd even make that 3770 if all the mail apps on the system are under control. Or use acls or SELinux to limit as appropriate, if y
Re: (Score:2)
On the upside, since I have a static IP at home, I just set up an MTA on my desktop, and send mail much much faster that using some external (innecesary) relay!
Awesome! (Score:3)
I'm glad that mutt isn't stagnating, and that there are people dedicated to keeping it awesome, relevant and supported. Rock on, you crazy forkers.
By the way, Mutt is an email client (Score:1)
Superpowers.. (Score:1)