
Mutt 1.7.0 released - tdurden
https://marc.info/?l=mutt-users&m=147154326009383
======
jvehent
Many people try to switch to Mutt thinking it will be like using gmail but in
the terminal. It is not.

Mutt is a productivity tool, like vim and emacs, but for email instead of
code. You need to invest a lot of time into learning it, refining your
configuration, and getting comfortable with its interface. It will originally
be as frustrating as giving emacs to a notepad user, but eventually pays off
the learning cost in productivity.

Some examples of commands I use all the time:

* shift+D deletes an entire thread. Very useful to delete entire github discussions in one command.

* `t` flags a message, then `;+s` moves the entire flag to another folder

* custom macros. For example, I use `short+C` to move the message under the cursor to folder `foo`. I have 5/6 similar macros for the folders I use most.

GnuPG integration is also a big help (I use it constantly). I'm use many other
MUA offer similar shortcuts and configurability, but Mutt is the fastest and
most flexible by far. The one thing that I haven't found a good solution for
is full text search across multiple folders. I still rely on gmail for that.

~~~
geofft
> _shift+D deletes an entire thread. Very useful to delete entire github
> discussions in one command._

If you enable keyboard shortcuts from Gmail's settings screen, "e" archives
the entire thread and moves you back to the inbox. "m" will additionally mute
the thread so _new replies_ don't show up in the inbox. You can also use "{"
or "}" to archive and move to the next or previous thread, instead of back to
the inbox.

> _`t` flags a message, then `;+s` moves the entire flag to another folder_

"x" selects the current thread and moves you back to the inbox. Then "v"
brings up the menu for typing which folder to move all selected conversations
into.

> _custom macros. For example, I use `short+C` to move the message under the
> cursor to folder `foo`. I have 5 /6 similar macros for the folders I use
> most._

"vfoo" will do that.

Gmail is also a productivity tool, and you should also invest time into
learning it and getting comfortable with its interface.

~~~
dredmorbius
Mutt is a productivity tool that's learned (or at least practiced) the wisdom
_that you don 't fuck with a productivity tool's UI/UX gratuitously_.

Google ... hasn't.

------
apatters
I love the snappiness and power of mutt but when I tried to switch to it as my
full-time mail client it didn't end up being an improvement. Not really due to
any fault of mutt's but because I disagree with the common POV that HTML email
is useless/the scourge of the Internet/etc.

What really ended up being the dealbreaker was that the viewing and authoring
experience for moderately marked up text was poor. Specifically: Quoting,
bulleted lists, inline attachments, and maybe a few other basic formatting
tricks. This kind of stuff doesn't end up rendering well when I view the mail
in a terminal-based browser like w3m, and I didn't even try authoring (am I
going to hand-code the HTML for every email I write?).

I wish we had something like Markdown for email--to me that would be the sweet
spot between the mess HTML email has become, and plain text which sometimes
does lack in its ability to communicate information.

Beyond that I would love any advice on how to use a terminal-based mail client
but still be able to author and view some kind of useful representation of
things like lists and quotes. Maybe with just the right configuration this can
be done...

~~~
contingencies
_I wish we had something like Markdown for email--to me that would be the
sweet spot between the mess HTML email has become, and plain text which
sometimes does lack in its ability to communicate information._

I don't use _mutt_ but IIRC a basic feature of both _mutt_ and similar (
_pine_ \+ variants, etc.) is allowing you to define your own external editor.
Therefore, there's nothing to stop you adding a wrapping pipeline to that so
that, for example, first you edit normally in your preferred editor, and
second an established piece of code or basic series of regex replaces your
markdown with whatever you actually want. Optionally, the reverse runs before
editing. This should not take longer than a few hours on the outside to get
running comfortably.

~~~
astrobe_
I think you are solving the wrong problem.

The problem isn't HTML, it is its users. People who can't quote properly,
people who end every single sentence with an emoji, etc. In a nutshell, people
who have never experienced Usenet never learned how to communicate properly
with a keyboard.

The fix for this is to configure your email client to auto-answer a rejection
message when it receives anything other than plain text. You can always blame
your antivirus for that.

Help people with disabling HTML email. With a little bit of luck, they won't
remember how to enable it again. And hopefully, since they won't be distracted
any more with fancy formatting, animated smiley and which GIF-meme-to-use-for-
this, hopefully they'll focus on words and reinvent ascii art.

~~~
apatters
With all due respect: your approach here is to tell a billion people to jump
over the Grand Canyon or kiss your ass and die.

My approach is to go as far as I must to meet them halfway because I know I
wasn't born perfect either.

Engineers are brilliant in ways that are rare, valuable and admirable. But
they don't tend to have a great level of empathy and trust me, it's something
worth cultivating.

~~~
astrobe_
I see every day people being owned by phishing and malware and their privacy
compromised because they are accepting HTMaiL.

I've heard people complaining about email conversations that they can't
understand any more because every one used together top-posting, bottom
posting, coloured inline replies and no trimming.

I want this madness to end. If it isn't empathy, what is it?

It's no different than telling billion people to stop using Flash or kiss a
specific part of my body and rest peacefully. Except perhaps that we are a few
anonymous "disgusting elitist curmudgeons" instead of being huge internet
companies.

------
wahern
Am I the only one who wishes Mutt loaded mbox files faster?

A couple of years ago I wrote an mbox parser that was several times faster
than Mutt's. It really showed because at the time my server was running on a
Soekris net6501, my mailbox was a few hundred megabytes, and my habit is to
invoke and exit mutt repeatedly rather than using a dedicated terminal window.
Since then I've been running my server on a Xeon E3, and it's less bothersome.

I investigated patching Mutt to use the parser, but it seemed a little too
much trouble for the effort given how many one-liners have accreted in the
existing implementation. Using an index would make things more responsive,
too, but the faster parser could provide competitive responsiveness into the
gigabyte territory while keeping things simple, in both code and on the
filesystem.

Is this a common enough gripe that it might be accepted and appreciated? My
parser used Ragel but I could implement it again in plain C so it didn't have
a build-time dependency.

~~~
notaplumber
I'd wager any mbox optimization efforts are put on the back burner in lieu of
modern usages, which seem to be in favor using it as a IMAP client only.

~~~
stevekemp
I'd agree with that.

That said there is an obvious solution to slow MBOX folders, which wouldbe to
switch to using Maildir-storage, then using the `header_cache` setting(s).

~~~
notaplumber
I personally don't mind MBOX, it's a simple format and if you archive it
regularly and don't let it grow exponentially, it can be nice to work with.

~~~
jabl
mbox is fine for a read-only (or at least append-only) archive. It's when you
start deleting messages, changing flags etc. in the middle that it becomes a
pain.

------
alxprc
This release is particularly interesting because it includes the sidebar
patch, which has existed in various forms for about 10 years [1].

Mutt has generally been quite conservative in accepting patches. NeoMutt [2]
is a project hoping to kick-start development on the Mutt project, by being
much more willing to accept contributor patches.

The repository [3] is becoming more and more active; help is always greatly
appreciated!

[1]: [http://www.lunar-linux.org/mutt-sidebar/](http://www.lunar-
linux.org/mutt-sidebar/)

[2]: [http://www.neomutt.org/](http://www.neomutt.org/)

[3]: [https://github.com/neomutt/neomutt](https://github.com/neomutt/neomutt)

------
stevekemp
If you like console-based mail-clients you might want to checkout my own
project:

[https://github.com/lumail/lumail2/](https://github.com/lumail/lumail2/)

This is directly inspired by mutt, but uses a real scripting language (lua)
for most of the operations. It allows you bind keys to lua-functions and so
on.

~~~
shakna
First, this looks really cool.

Second, and sorry if I missed it just glancing over the project, is there a
way to tweak the views, like with ```message```? (Wondering if I can insert
pandoc or the like to change how it displays in the terminal)

~~~
stevekemp
Might be best to file a bug-report if you have questions/feature-requests.

But see HACKING.md. In brief the display of mode X comes from the output of
the function "X_view()". So you can change the rendered text there by updating
that function.

So for changing the message-displayed you'll want to tweak
`message_view(msg)`, and can add rendering there.

Hope that helps.

------
janvdberg
Complete changelog:
[http://www.mutt.org/doc/UPDATING](http://www.mutt.org/doc/UPDATING)

"Please watch for airborne bovine."

------
carlesfe
On the topic of console email clients, why does Mutt receive so much love and
Alpine doesn't? I used Pine for many years in college and I really liked its
menu interface and its ability to read news.

I used Mutt some years ago and found it too complex for the task. Maybe it's
becaused I was used to Pine.

Has somebody used both recently and can elaborate a bit? Thanks!

~~~
exDM69
May be due to Mutt's more Vi-like user interface. Vimmers use Mutt and Emacs
guys use emacs-based mail user agents. There aren't too many people preferring
terminal mail apps left for Alpine.

~~~
bshimmin
Just to be contrary, I happily used emacs and Mutt together for about a
decade.

(I wanted to start using Mutt again earlier this year, but so far the labour
of love involved in cobbling a good .muttrc together - without just copying
bits and pieces from other people's - has proved too much like hard work, and
I have enough of that as it is.)

------
znpy
I used to use mutt, but I switched to Thunderbird because I now have to track
more than one mail account and like having a clear overview of all my
accounts.

I al perfectly aware of the fact that mutt can handle more than one mail
account: I used to change settings with chdir hooks and stuff like, but
honestly, it's quite an overkill.

------
tanderson92
One problem I have had with mutt and I don't see it fixed in the current issue
relates to GPG support. It appears that when I send an encrypted e-mail, mutt
does the obvious thing and saves the encrypted e-mail in my sent folder. But
that's encrypted /to the receiver/, not to me. Hasn't this bothered enough
people for mutt to fix it, so that GPG-encrypted e-mails are encrypted-to-self
when copied to Sent?

~~~
travisb
There are at least three ways to solve your problem:

1\. Use fcc_clear=yes to _not_ encrypt the copy in your sent folder

2\. Use GPG's encrypt-to in your GPG configuration:
[https://www.gnupg.org/gph/en/manual/r1261.html](https://www.gnupg.org/gph/en/manual/r1261.html)

3\. Add --encrypt-to to the GPG commands mutt uses:
[https://dev.mutt.org/trac/wiki/MuttGuide/UseGPG#TheCodeSourc...](https://dev.mutt.org/trac/wiki/MuttGuide/UseGPG#TheCodeSourcerymethodofMuttsetupandexplanation)

~~~
tanderson92
Thank you for (2). (1) is not an option for obvious reasons, but I had been
using (3) and it was not working as claimed. I'll try (2).

------
hossbeast
I'd love to do email in the console, but I have the impression that it just
wouldn't work with my corporate email servers

~~~
geofft
Exchange's IMAP and SMTP implementations work fine. The only really awkward
things I've seen are that IMAP search doesn't quite work and calendar invites
don't do the magical thing you want. But it's definitely reasonable to use a
text client for most things and pull up OWA for the occasional edge case.

Honestly, it's Gmail I've had more trouble with, because labels aren't really
folders as the IMAP spec envisioned.

~~~
dx4100
So, serious question: Why do you use console e-mail?

~~~
curiousfab
Speed and efficiency. Very convenient keyboard only use. Highly configurable
and scriptable. Available from anywhere with ssh.

mutt does many things out of the box that other programs cannot do or just
with plugins and/or inconveniently hidden functions. Some examples of things I
frequently use:

\- bouncing mail

\- re-send incoming email (after editing it)

\- changing headers of composed emails on the fly

\- show (only) certain headers by default

\- using your editor of choice for composing mails

~~~
dfc
Why do you need to frequently change email headers?

~~~
curiousfab
Examples:

\- Add "Approved:" headers for moderated/closed mailing lists

\- Add or remove In-Reply-To headers as needed (remove if I reply to an old
mail but it has nothing to do with the thread; add if I reply to a mail from a
mailing list that I don't have any more but I have the message ID from an
archive)

\- Change the From address.

------
adrianratnapala
Does this new release include a sane concept of multiple accounts? Or are we
still stuck with hook voodoo?

------
dredmorbius
I haven't seen mentioned:

* Is assigning specific tags to messages (or labels) supported? What's the interface like?

* Any fast searching/indexing options?

* Anything, generally, for improved behavior with Gmail?

------
epse
And it is already in Debian Testing! Dear maintainer, thank you!

