Interestingly, I went the other way. I used to have mutt for years, then went through a dark phase (macOS Mail.app, Evernote and Things) and finally concluded to Emacs with mu4e.
Integrating mail with Emacs was the best idea ever, because Emails include either todos or serve as reference in projects. Creating todos from Mails as well as linking to them from org-mode is only a shortcut away.
I have never had a more easy to manage and productive todo management system - and it's all text, so there will never be breaking changes or paid upgrades or incompatibilities between tools that I cannot fix.
I have also been using an emacs (spacemacs) + org + mu4e setup for 6 months or so. Unfortunately, everything seems to be really buggy and break at random moments. Also, there isn't a really good iOS integration story.
So, I am slowly retracting and going back to vim, Mail.app, Things (and mutt every now and then ;)).
Well, you're using spacemacs. I know it's super popular, but it's also a huuge configuration which changes defaults. So updating will always be a little dangerous.
I'm not trying to be mean, it's a great project, of course.
I have my own configuration on top of vanilla Emacs and have never had any problems with things stopping to work.
As for iOS I don't need more than what MobileOrg has. I need to add new todos and very seldom look stuff up. Both work totally fine. And I'm saying this after having been a paying Evernote and Things user for years^^
Do you use GMail? If so, how much pain is was to configure your setup to connect to it reliably? And handle multiple e-mail accounts?
I ask, because in the past I toyed with switching to using Emacs as my e-mail client, but aways got stuck on configuring the whole setup to work reliably and seamlessly.
One trouble I had while configuring for my gmail account was the lacking support for Google's XOAUTH extension for SMTP and IMAP authentication. After a little research, I found that you can create app passwords[0] in Google after you've activated 2FA. This allowed me to use standard PLAIN authentication with passwords that don't allow for management of the whole google account.
Thanks for the config. I'll be getting to setting up mu4e after the OfflineIMAP sync finishes (some time this week, hopefully ;)).
How's your experience with literate config, in terms of managing it? I've been meaning to switch from my mess of individual files to something like this for a time now.
I'm using offlineimap, too. It's not running longer than a program like Mail.app when it has been synched once. The first run, of course, might take a while if you have lots of mails(;
Regarding literate configuration: It's been super easy, honestly. I used to have a longer init.el (formerly super long vim.rc^^). Once I wrote a short macro that converted comments into new headings in org to get me started. Then, every time I touch something, I just add a little more documentation to guide me and others for the next time. It's not more work than writing a regular init.el with comments, but the result is so much more powerful (folding->refactoring, documentation on Github, etc).
I use Emacs + mu4e with 2 GMail accounts (personal & work). AMA I guess.
I use OfflineIMAP to sync the two accounts to ~/Maildir/{work,personal}, then mu4e-context to switch between settings for the two.
I entirely outsource actually sending the mail to a local exim4 daemon which is configured to forward through a GMail smarthost. IMNSHO this is much better than the recommended default configuration of making Emacs actually send the mail, I don't have to worry about not having a network connection at the time, or some other transitory error with a real smtpd retrying the send if needed.
You then may need a tiny hack on top of Debian's default exim configuration to make it switch between different smtp servers / accounts depending on what address you're sending mail from. For reasons I won't go into I send E-Mail through a company-run SMTP server even though I then fetch work E-Mail from GMail.
Thanks for the tips. I'm trying OfflineIMAP now (it's syncing... there's few gigs of e-mail to sync...).
I'll definitely consider your trick for sending e-mail - I definitely value both Emacs not hanging and also having the ability to send e-mails off-line.
for me the only thing that i found that worked is Zero Inbox.
i get a lot e-mail per day, most of them are not actionable ( notifications, statuses, replays for other departments and so on ) i archive them, and the ones that i have to handle are moved to wunderlist or replayed right away.
this is the only solution that i found to work for me.
I know that i have to handle it now inside wunderlist. but it works ok for me because is better sorted.
i use evernote for some of the stuff, and i try to write everything. sure its not ideal but it is a lot better then it used to be where i would forget about some important stuff.
I did the same! With Things instead of Wunderlist.
But my links to mail from Things and EN kept breaking. I also work with Inbox Zero and that's the primary reason for my switch - without references it got worthless.
I use Emacs (with Spacemacs) + Notmuch with mbsync to pull in new mail and msmtp for sending mail. It works pretty well and it's easy to find old messages, which is the sort of thing I need the most from my email.
There are lots of these around, but if you're interested in trying it out I have a pretty simple Spacemacs layer for Notmuch as well.
Same here. I am a long time mutt user, but recently switched to gnus. Have you considered gnus instead of mu4e? Gnus is notoriously hard to set up, but I found it has some remarkable features.
> Gnus is notoriously hard to set up, but I found it has some remarkable features.
Maybe things have changed now, but several years ago I wanted to setup Gnus, and asked for help on IRC (#emacs IIRC) because there weren't many good resources online. The response was "if you need to ask for help, then Gnus isn't for you."
Honestly, that's probably true. Not in some elitist, "if you have to ask, you're not smart enough" kind of way, but in a "if you have to ask, then you're the kind of person for whom figuring out how to set up an esoteric email program isn't fun, and you're not going to like it much here" kind of way.
Gnus is fairly painful to set up. I did write something up several years ago about getting it going the way I wanted (http://www.cataclysmicmutation.com/2010/11/multiple-gmail-ac...). I haven't used Gnus for a few years now, having first gone to mu4e and now due to corporate fun, Microsoft Outlook, so that document may or may not be currently useful.
Well if you need to ask basic things that means you haven't read the manual, which can easily get you going with a relatively fancy setup. People naturally don't like explaining things that are already explained in a manual that's a C-h I away, hyperlinked and friendly. Emacs is one of the few projects that have good docs, and probably the best among them wrt the accessibility and ease of use of the manual. And still some people hate on Info, probably because they don't read/write documentation at all...
I did look into Gnus and saw some amazing features there.
However, mu4e is pretty straight forward and has a strong search engine included which means that I can use my setup on both Linux and the Mac. As I understand, I would need to set up a local mail server for Gnus if I wanted reasonably fast search. Having multiple (and sometimes changing) mail accounts that I would need to configure on multiple OSs kept me from doing that.
So to me, mu4e is easier, though Gnus might be simpler in the true sense of the word.
Not saying that Gnus doesn't have merit, though. It's a fascinating piece of engineering. And when I get older (already old^^), and only have one business running in parallel and no more need for the Mac, I'll probably switch(;
Not OP but the best email client in Emacs is RMAIL. So dead simple that you can teach it to your grandpa in a couple hours. I use Gnus because it does nntp thus helping me keep my inbox clean while still being able to follow many mailing lists. Also, many times people don't CC you when responding on lists so if you don't gmane+nntp, many times you don't get the responses without subscribing. I wonder what weird programs these use.
The company I work for is big-ish, ~10k, and many use mutt, emacs, Thunderbird and some even use a mailing-list<->nntp with slrn.
I think it all depends on which area of work you are in. For software engineering folks it works just fine.
I for one use mutt and handle calendar invites with gcalcli, I can use LDAP lookup and HTML mails are converted using elinks and read inside mutt. If I want to see all the fanciness I just open the text/html attachment in Firefox.
They probably also use Outlook. That's what I do (4K employees). Used to use Mutt almost exclusively, but just became too hard and people complained about my emails turning everything to Courier. :)
I still use Mutt to quickly prune emails in the AM and for writing to mailing lists.
I've (sadly) gotten pretty used to Outlook and like it quite a bit. I do miss using vim to edit emails though...
Calendar invites are just attachments, you can handle them in external scripts and programs any way you like. Personally I just display them in plain text next to the email, but if you wanted to interface them with your calendar application I'm sure there are plenty of scripts doing that out there.
As for HTML email, what I take from this entire thread is that I either I've been extremely lucky so far or people in general vastly overestimate the importance of it. For one thing, most decent services will send multipart/alternative emails that are suitable for plain text display.
For instance Amazon's emails use rich HTML features, but they also have a text/plain alternative that works perfectly in a text client and carries the same informations. And when there's only HTML the vast majority of the time it's still mostly text with some light styling and it works just fine (sometimes better) in text mode.
The main problem working in big companies and using mutt as my client is that most of the time those systems have a 2nd class non-compliant IMAP servers and you have to go through oops to reliably receive and send your email. I always managed to get it to work after some tweaking though.
You're right that most services do send a multipart message with a sane looking plain text version.
The biggest issue with that is when the sender of the email doesn't actually check that the content was converted properly. Most notably, hyperlinks in the HTML get converted to the text of the link and the URL in question is no where to be found.
Even if most HTML emails send perfectly created plaintext versions (and yes, Amazon is great at this), you'll remember the crappy unreadable HTML-only emails far more than the normal looking multipart ones with proper conversion of the HTML to plaintext.
My first job in high school involved formatting and sending out email blasts. Even at that point, I was aware of potential formatting issues and I took care to make sure that the automatically generated plaintext version had all the same content. For that reason, I have no patience for HTML-only emails crafted by grown adults.
TBH, I'm starting to think people that work in big companies need this the most. Outlook's filtering configuration is fairly limited compared to what you can do with a well setup procmail system.
I agree. I work in a large-ish company (~9k) who a few years back moved from Exchange/Outlook to GSuite (with POP and IMAP disabled) - so using anything but the Gmail web interface and/or the mobile apps is out of the question. Add in the obligatory (and yes, slightly annoying) corporate managed email signature (HTML), the fact that everyone is used to just copying images/screenshots inline with the text, and of course the very tight google mail/calendar/drive integration, and I don't think that even if I could use a text-only client outside the Google ecosystem, it would be a viable option.
"Data Leakage Protection". The idea being that the everything that ever goes in or out of a mailbox is recorded, audited, etc. Yes, deleting an email/thread doesn't remove it from Vault, but this way, other than copying/pasting from the browser window into another client, there is always a trail of where an email went, and users can't "take home" a dump of their entire mailbox. When legal get involved and need a dump of "every email between employee X and external party Y", there is no question of whether a different SMTP server was used so we may not have a record of the sent messages, etc.
It's probably pretty weak for me to admit, but I accept calendar invitations on my phone. As you say, accepting them in Emacs or Mutt doesn't seem worth the hassle (I get a handful a week).
At this point, it's pretty rare for me to get an email that I need to read that I can't, mostly those are spam or sales messages. Where I work, the company uses the "G Suite" of products.
This is all very nice, but the fact that the article doesn't even _mention_ images or attachments shows how divorced it is from the reality of most people's email experience.
I happily used emacs as my mail-reader from 1989 to about 2009 (first RMAIL mode, then VM). The increasing importance of non-text formats made it cumbersome, and I somewhat reluctantly switched to GMail. It's hard to imagine switching back now.
I have to agree. After years using Thunderbird, I switched to mutt in 2015 and used it as my unique email client till a few months ago, when I switched back to Thunderbird. Despite its fantastic speed, the difficulty to handle attachments is what set me back.
I am a researcher, and when my colleagues want to discuss results they have the nasty habit of sending plots and documents as email attachments. My most important emails have PDF documents or plots attached, with the email text commenting the attachment itself. The problem with mutt is that it allows you to start helper supporting application to open attachments, but it waits for the application to finish before returning to the email text. This is not what I want, for I obviously have to read the email and view the attachment at the same time!
The usual trick here is to fire the application in background (using "&"), so that mutt can resume operations immediately after the helper application has started. The problem is that once mutt resumes, it removes the temporary file containing the attachment, so if the helper application starts slowly it might not find it. One can force mutt to wait some seconds after having launched the helper application, but this not helps if the attachment is a multi-page PDF file, because once the wait has expired, the PDF file disappears and is no longer browsable.
I must say that using mutt was an enlightening experience (email browsing can be fast, after all!), but thunderbird makes me far more productive.
Images are opened like any image on your system: by using an image viewer.
For non-text formats, I only deal with HTML. For them, I pipe the mail through a terminal-based browser before reading it. All of this is done automatically, literally a one-line configuration in the proper file, a thing that is explained at length in most mutt guides.
No one is questioning one's ability to look at an image attachment through an image viewer. I think you know this, which makes this sort of reply doubly frustrating.
Think about how word processors were a thing so early in personal computers, despite then actually being some of the most complicated bits of software one can build. What are e-mails if not documents?
Having some control over formatting (at least in the semantic sense, like HTML) is a core part of using computers for a huge part of the population. Yes, even the people using only their phone. People like bolding text.
A lot of people aren't good at it, but a lot of people aren't good at talking either.
My GUI client blocks images by default and I almost never need to have the images display because all images are from advertising(maybe for other people use case they get more images)
> There's also another. Navigating TUI with Vim key bindings is very fast
I'm a heavy VIM user. Gmail supports VIM keybindings and there exist VIM keybinding extensions for all popular web browsers, i.e. Vimperator on Firefox.:wq
Many years ago, a mail reader, whose name temporarily eludes me, touted as one of its features that for the most common use case it could be driven with just two fingers on the numeric keypad, one for the enter key (which paged down and went to the next message) and one for the Del/. key (which skipped threads).
i seriously doubt that its faster than the normal keyboard bindings and mouse. and i enable vim mode in any editor i use.
and even if it were the truth: navigating mail generally consumes the least time... actually reading the mail and deciding what to do about it takes way longer.
another activity where a scroll wheel is invaluable.
> Graphical email clients are universally buggy and slow. That's the advantage of mutt.
that's what they said back in the early 2000s too, so I tried it, but I was appalled by the horrible support for message threading and IMAP support that was missing most of the features you'd expect an IMAP client to have plus the stuff that was there was full of bugs.
I'm sure this has gotten better by now, but a blanket statement of "Graphical clients are buggy" is totally not valid. All software has bugs and depending on your priorities some might be worse than others.
* A good integration to the rest of my IDE. I need to save a chain of email as .mbox to `git am` them afterward. I have this workflow with mutt, I don't know which graphical email client would allow me to streamline this.
* In the same vein, I need to be able to use only my keyboard. I tried a little using a web client with vimperator. But the gmail interface wasn't really easy to use, I prefer using mutt properly configured.
* I also like writing my emails using VI. Having those keybindings is a proper crutch, but it's not there for text editing.
* Finally, it allows me to have a transient workspace. I can SSH on my main machine from wherever, do a `tmux attach`, and I have absolutely everything available: access to my emails, but also integration to my other tools for email analysis / processing.
This all stems from workflow derived from ancient practices, that's true. When I was starting in the industry I mostly used graphical tools. More and more however, I tend to rely on purely TUI tools. I have a few things that I can simply not give up anymore (grep, find, sed, awk, as well as full access to git).
I only use the web for accessing articles or content aggregator like Hacker News, as well as streaming music to block the open space. Ah, yes, patchwork remains web-based, I haven't really used pwclient. When I have time I will look into this.
It's a use case thing. I would argue that for most people who actually still use email for communication with peers, images and attachments are an afterthought. For images, we have image hosting sites, and for attachments we have a plethora of cloud hosting services that allow you to send a link instead of the entire attachment.
That said, there's a happy medium between console based email and bloated, buggy clients like Thunderbird. Claws Mail is a very old-school graphical client that supports modern email features, and it's about as tweakable as it gets.
> for attachments we have a plethora of cloud hosting services that allow you to send a link instead of the entire attachment.
Is there an email client that, when you drag a file icon into the composition window, doesn't attach the file but instead uploads the file to cloud storage and inserts a link? Now that I think about it, that's basically what Apple Mail's Mail Drop feature does (file is uploaded to iCloud, I think on send, recipients don't have to use Apple Mail and the file only remains on the server 30 days).
Thinking about the usual steps to attach a file compared to including a link to a hosted file, I think the latter much more takes one mentally out of the composition mode to deal with the hosting/sharing; dragging in a file attachment
"I'm writing an email that references a file. I get out of email to find the file. I'm dragging the file into the message window. I'm sending the email, it seems like its taking longer to send because it's a large file attachment."
"I'm writing an email that references a file. I get out of email to find the file. I move (or copy) the file to my cloud storage place (Dropbox, Google Drive, etc.). I set the file to be shared. I copy the link to the file. I go back to my email and paste the link (or write some link text in HTML email and paste the URL). I'm sending the email."
>> Is there an email client that, when you drag a file icon into the composition window, doesn't attach the file but instead uploads the file to cloud storage and inserts a link?
> I would argue that for most people who actually still use email for communication with peers, images and attachments are an afterthought.
Are you actually convinced of that, or are you being inflammatory? Because, in 2017, it's hilariously far afield of most folks' email use patterns both at work and at home. Do you only ever communicate using text -- and plain text at that?
I work for a small software company - ie, full of nerds. We use screencaps marked up in email ALL THE TIME to communicate about changes and whatnot. Sure, I guess we could put it in a Word doc or HTML doc, but why bother when we can do it in the email client?
I was under the impression that most software houses and tech startups migrated to Slack or similar group messaging long ago, which offers much better handling of attachments and collaboration. Email is still heavily used in government, mostly on Exchange servers, and I can see attachments being a big thing there (I work for local government and that's our setup). In the home consumer world, it's nearly all iMessage/Hangouts/SMS/WhatsApp etc.
Again, these are my observations and perhaps my window isn't big enough.
I can only speak to my experience, but email is very very much a part of our world in our software company. It's WAY better than Slack or other IM/group chat tool for search and archiving later -- and, let's be honest, a WHOLE LOT of stuff gets decided in email, so that's pretty important.
With a distributed team, it's even moreso. Plus, since we're distributed, the idea of email-as-document (with rich formatting and inline images) is just that much more normal.
Part of my duties at work include help desk and maintenance of a few pieces of software. I get eMail with screen shots of error messages on a fairly regular basis.
(Personally, I have made my peace with HTML eMail, what I really dislike are those humongous email signatures with corporate logos and silly disclaimers that often dwarf the email body itself.)
Normal people absolutely put images in their emails.
Email clients like gmail/outlook put images in the content of the email (NOT an attachment) when you drag/drop files onto the window or when you copy/paste a picture inside the mail.
There was a time when this all went to attachment, that is not the case anymore.
Those images are effectively attachments that are referenced in the markup of the HTML. You can still view them just fine as attachment in mutt.
Sure it can be cumbersome if the various images are interleaved with commentary, but in my experience 99% of the time it's "Here are the pictures/documents you wanted" followed by a few attachments (inline or not).
There's a very, very small proportion of emails where HTML is actually mandatory to make sense of the contents. And for those I can just tell mutt to load the HTML in my web browser. I very seldom have to do that though, not enough to be a real nuisance.
Normal people then don't use email for creative work involving designs, mockups, sketches, etc. And yes, it kind of sucks to have the image opened out of its context in new window. Did you notice how HTML got successful by interleaving text and images?
Inline images are incredibly helpful when explaining things via email, which can be hard enough as it is. Imagine a textbook where all the diagrams were at the end of the chapter and you had to keep flicking between pages to refer to them. You have to imagine that as it doesn't exist, for some reason.
My colleague makes these images-with-commentary emails every week. For when I need to view those, I hit `H` in mutt, which opens the email in my web browser.
That does sound like a possible work-around, I might try moving to mutt again. But what about when you want to create one of those yourself? Or to reply inline to parts of theirs? How is that handled, do you write HTML?
One of the few reasons I have to mess around with NoMachine etc is for email, if I could get it in a terminal over ssh that'd be great. I did try a few years ago and after wasting a lot of time sorting the config, the lack of good reading experience for rich content emails was enough for me to dump the whole thing.
I've started playing with building a drop-in replacement for msmtp that converts markdown to a multipart email, but honestly I never actually need to create these kinds of emails, so that little project is on the back-burner.
The extra step and use of an external program is pretty inelegant, IMO, when there exist clients that will just show you the damn image in the mail window.
> Imagine a textbook where all the diagrams were at the end of the chapter and you had to keep flicking between pages to refer to them. You have to imagine that as it doesn't exist, for some reason.
I don't know if you are joking, but this was not uncommon for quite some time. It used to be that color printing was much more expensive than black and white. Text books often only had a few pages with illustrations and images in color. The color printed sheets were added last so they ended up exactly in the middle of the book.
Normal people send me pictures in emails all the time. Very often it's a screenshot of something where they have drawn a circle around some part and written some variation of "this part is wrong" or "can you take a closer look at this".
They shouldn't but they do. Almost every time someone sends me an image I think of a better place they could have put it. Attached to the ticket in our ticketing system, in our bug database, on our file server, etc
Sure they should. It depends on the tools available and the culture of the organization.
You don't get to dictate what features of email people should or shouldn't use.
Apple's Mail.app has a great feature that allows inline markup of images, which is a huge boon for interface discussions and tech support emails at my company.
I work in Service Department. As a regular part of my job, I put images in emails. I have to show people how to do things, and putting them as attachments and not inline would not be helpful.
At my old job, as an engineer, I also put images inline. I got emails all the time, or calls, asking why is this? The easiest way to show someone is in an email, with a screenshot.
Its not any different than an article in a newspaper or on a webpage with an inline image. It actually just works.
Despite my "Why Be Normal?" visor, I consider myself mostly normal. I send and receive email with inline images. Sometimes they're attached, which is usually annoying, unless they really aren't part of the narrative.
This is absolutely not true. Generally speaking, people whose experience leads them to think this are in weird isolated silos where highly technical folks are overrepresented.
I use emacs for my mail, with the notmuch mail package which gives me Gmail-like search ability. w3m is used to display HTML email in the emacs frame, and it does a good job with tables and inline images.
I find the emacs editing experience so superior to anything else that I feel hamstrung in Gmail or Outlook.
I used mutt for several years as my primary email client. Once I got it configured, I was able to handle attachments reasonably well. The thing that killed it for me was inability to integrate with Exchange server at my office, for accessing addresses when sending and for responding to calendar invitations.
I've used Thunderbird, Gmail and now mutt for my e-mail needs, and so far I've liked mutt the best. For the communication I do via e-mail, it's very rare that the non-text content is very important, so the text only mode allows for more focused experience. Besides, Gmail is never far away, just a matter of opening (or finding) the browser tab.
In mutt you just hit "v" for instant access to the images/attachments/{html only emails} ... which is as fast and convenient as security conscious graphical clients that don't show images by default. I really don't want my client to run an html interpreter without forethought.
Like others here I'm using mu4e in Emacs and it does a fine job at displaying images. It can also switch to rendering the HTML email in the same buffer.
I started using Emacs's mu4e package for my email at work. It's mostly mail from Github about pull requests, so no fancy HTML or images in there. I also integrated a small shell script I wrote to fetch a patch from a private repo on Github, so that when I open an email, if there is a link to the pull req (e.g. https://github.com/org/repo/pull/123) I can open the patch directly inside Emacs. Since I don't like to review code in the browser, this is quite helpful to me. In addition, by staying in Emacs rather than going to Firefox, I am way less likely to open HN or lobste.rs and start reading.
This is in part a cultural thing. Within GNU, many are hostile toward non-plaintext e-mail and might even ask you to resend plaintext. But we're a group of people that live and die by text. Many hackers are extremely efficient in processing text. Adding document formats like HTML into the mix muddies things unless you have very specialized tools for dealing with it.
And then you have people who start using formatting semantically, e.g. colors.
Now, with all of that said, Emacs does a remarkable job of rendering a subset of HTML. For example, I have my mail client configured to always ignore HTML alternatives unless they're the only option. In that case, colors and tables and such are all rendered as they should be. Inline images might be supported if you use a graphical version of Emacs (Emacs can definitely display images, I just haven't tried in this context); you also have the option to open it in an external viewer, like a web browser.
I think emacs can probably do a reasonable job of processing and displaying the subset of html that is often used in email. For anything really fancy you can open it in a browser (which is something I regularly do in outlook as well).
The only reason I still open Outlook regularly is to deal with calendar invites. Otherwise, gnus actually works just fine for email. Better, in many ways.
attachments yes, but images? There's literally zero reason to have any images in emails. Use Dropbox/Owncloud/Instagram/etc links if you want to share pictures. That's more handy for other people anyway instead of handling 2 gig of attachments for seeing your email on their smart phone.
Over the last 10 years I have worked with 4 digits worth of people. Managers, sales people, engineers, family members, locals, Western foreigners, Arab foreigners, Asian foreigners. I can't remember a single communication where direct insertion of images was a desired feature. If at all images were in emails because the email clients interpreted adding attachments in image format as part of the emails content (gmail client for instance).
I'd argue that images in emails means that you haven't reached 2017 yet, where there are loads of better options to share images.
I'd argue, in turn, that your experience, regardless of how many people were involved, is divergent from the way in which email itself is moving in the broader market of users.
Images as links to something else, that require an additional step, are an inferior substitute to inline images. Here in 2017, it's possible to build an email that includes tables or screenshots or other rich media that exist as part of the email itself.
This is commonly viewed as a benefit. 20 years ago, I, too, was resistant to the idea that email should be something other than plain text, but I was wrong. That ship has saild. Email today is a rich document, and rich documents often include meaningful inline images that should be stored with the document.
Again, that YOU don't like this doesn't mean it's not useful or widely used by other people.
But where is this kind of email happening besides the spam box? The way you argue this should be common and hit me in the face every day no matter my resistance. What I see is that less and less fluff is added to emails. A lot of work emails don't even contain a footer anymore, less and less people actually use greeting formulas, in some regards the whole communication moved from emails to other media like social media (even at work, where it is just a inhouse FB clone instead of the original).
Can you name a few examples of such rich media emails you recently received or sent and to/from whom (categorywise, e.g. family member, colleague, customer, department type)?
Obviously, people use email in different ways. This thread seems to have attracted a large number of people who exist in a text-only email world, but nearly every email I send or receive includes at least some rich formatting, and it's very common for us to include inline images of screenshots or other graphics as part of these emails.
And we're not web designers. We make project management software.
So: for me, mostly work email, though I certainly get no small number of personal mails with photos attached.
Again, that YOUR experience with email doesn't include rich text or inline images outside your spam folder doesn't mean those features are valuable and useful to other people.
I spent quiet some time setting up mutt or trying to make a real IDE out of vim or Emacs, but in the end it's just cargo cult and waste of time. There a modern email clients, IDEs, polished operating systems, etc., all built in this century. There is absolutely no need in wasting time scoring nerd points.
Emacs is not just an editor and mention it next to vim or mutt indicates that you misunderstand what Emacs tries to be.
Emacs gives you tight integration for everything that could possibly be represented as a buffer. Emacs is programmable glue between applications, a better "shell".
The desire to do all things in Emacs is because Emacs lets you do it and because it reduces context switching. For more on why one would want to make Emacs do things that are not traditionally the job of an editor, see also https://elephly.net/posts/2016-02-14-ilovefs-emacs.html
I get the point about Emacs being a OS, but don't you think it's kind of a dated clunky OS? Like "Mac OS 9" was, lacking memory protection and pre-emptive multitasking. Why would anyone want to be limited by technology when the rest of the world is moving forward?
But, just as it is a mistake to blindly cling to the old and comfortable, neophilia is a trap in itself. And it is a bit amusing to watch, for instance, new crops of editors repeat the same mistakes old ones got through in whatever GUI drag is trendy is this week.
For your Mac OS comparison to make any sense, you'd have to point to something comparable to lacking memory protection. So... what would that be? I have a sneaking suspicion you mean GUI integration with whatever OS you use, but I'd like to be clear.
> But, just as it is a mistake to blindly cling to the old and comfortable, neophilia is a trap in itself.
Agree, there is always must bee a meedle path.
To answer your question about MacOS 9 comparisons, I meant technical limitations, like single threading issues, ui capabilities, you know. I may be wrong, though, I haven't paid attention to Emacs intervals for a while. Modern web-based platforms are far from perfect, but they are reacher.
I'm still using the GNU system as my OS :) But Emacs is a very important "sub-environment" in my OS; it has a very privileged position in the process tree, much like a browser.
Emacs lacks a couple of features and I think it's fair to say that this represents a limit, but I don't see "the rest of world [...] moving forward" in this area. I don't know of any other system that is as ambitious as Emacs, a system that embraces the overflowing kitchen sink and isn't content with just being called an editor.
Out of the box it's terrible, I give you that. Clunky and dated are too nice for describing the defaults. But underneath the extremely conservative and curmudgeon defaults lies a very flexible environment that cannot be approximated with a set of text applications running inside a terminal emulator. It's a pale shade of the same colour that made Lisp Machines so attractive.
Operating systems that pre-dated MacOS 9 had pre-emptive multitasking. MacOS "moved forward" by adopting one of them (NeXT OS) and building their platform on top of it. I'm really unsure what point you're trying to make here.
I'm trying to say, that at that period of time, MacOS 9 was stuck in the past, even compared to Windows. This was in reference to Emacs limitations as a platform.
The vi vs. Emacs editor wars are over and Emacs lost. The new struggle is between vim and modern IDEs and IDE-like editors (Atom, Sublime, etc.).
There are reasons for this. Vim is retro like beehive hairdos; Emacs is retro like casual workplace sexism. The buffer implementation in Emacs sucks. Once you start opening huge files or running shell tasks that spew a lot of output, Emacs chokes hard and because it's not multithreaded, pegs your CPU and locks up your terminal, in buffer sizes that modern editors handle easily.
Also, Elisp is slow, contains warts the Lisp community has long since fixed, and is in general a millstone around everybody's necks.
Also, the UI. Just... the UI. Wonder why the best way to get a young developer to use Emacs is to reskin it like vim (evil-mode, Spacemacs)?
Editors, even all-in-one kitchen-sink editors, have moved on from Emacs. Just let it go.
I learned vim first and later switched to Emacs because it allows me to integrate all tasks in the same work environment. The defaults are admittedly terrible and it's certainly far from perfect. But I don't see any alternative that works better for the things that I use Emacs for. I am looking forward to eventually be using Guile instead of Elisp, though.
Curious that you mention the UI as a negative(?) --- the Emacs UI is pretty good actually and it's very extensible.
I have to strongly disagree with your "cargo cult" and "waste of time" comment. Everyone has different needs and expectations and I have found managing my email in Emacs to be quick, easy and straightforward. This could be in part because I receive more mail that I need to read and comparatively little I need to respond to directly.
While I do use Emacs as an IDE (I do some work in Clojure), I have another instance that I keep open and use solely to manage myself: email, calendar, list of to-do items and their status, miscellaneous notes, etc. At one point I had separate tools for each of these functions but over time I've decided that specialized tools aren't really worth the hassle. Emacs works just fine and everything is in one spot and easy to find.
> There is absolutely no need in wasting time scoring nerd points.
You're completely missing the point.
Sure, some people might do it to score points with their peers, but many of us use text-based clients because it fits well within our workflows. I used to use Mutt, because I do everything except for graphical web browsing (literally) on a terminal. I switched to Gnus in Emacs because it's heavily scriptable and has very convenient integration with Org Mode.
I'm sorry it didn't work for you, but your hostility about it gives me the impression you became frustrated configuring advanced stuff that perhaps you don't understand or need. If you never, say, want to select a group of messages based on a regular expression, absolutely, stick with Outlook or whatever. If you never need different contextual handling (say, signing mail only from a particular account, add particular headers when sending to some address, etc.), then I'm sure the configurability looks stupid.
Put another way, you can complain that a pickup truck isn't a Prius, but you should expect people who use (not just drive) pickups to snicker.
I use mutt (and vim, but that's a different post) heavily because it saves me so much time. Sure, there's a learning curve, but there is no faster mail client out there for handling large volumes of mail.
Speed:
- It is entirely keyboard driven.
- Until you have >6 figures of mail in one mbox, every action is essentially instant. And then you only wait a bit on load/save.
- If you have to deal with automated mail systems and the occasional mail disasters caused by them, the regex manipulation is a godsend.
- I think people don't notice the little delays in GUIs, but when you're going through hundreds of messages, it adds up.
Other awesome features:
- If you ever have to deal with GPG, mutt is the place to configure it. I don't use it much, but it is part of the workflow for some open source projects. I've configured it in various GUI MUAs, and it seems like every time I do try to sign something, it broke in some annoying way. Mutt is loosely coupled enough that that doesn't happen.
- Works over ssh. Yes, this absolutely matters to me - can't live without it.
- Extremely extensible. Add a configurable MDA[1]. I've built entire little adhoc apps based on email for various purposes.
[1] I actually still use procmail, because the syntax ate by brain a long time ago, but I'd recommend something less obtuse if you're starting fresh.
Sorry, I didn't mean it to be hostile. But you're right, I'm expressing my frustration, perhaps a bit sarcastically. Of course everyone's needs and preference are different, I'm not trying to say I am the source of wisdom, just sharing my thoughts, you know ;)
Totally fine - I do devops; software ensures my life is suffused with constant low-grade hostility.
Mutt is a bit old-school. It absolutely assumes rather more familiarity with how mail works than most other MUAs, and the configuration isn't very... ergonomic is the wrong word, but close. Combined with man(1) style docs, there isn't a good way to distinguish obscure knobs one would rarely want to touch from things everyone configures, for instance, unless you're already pretty familiar with what's going on.
In a past life, I spent a noticeable fraction of my career dealing with email from several angles, and love mutt. But if you've made healthier choices, I can absolutely see being bewildered and frustrated by it.
> There is absolutely no need in wasting time scoring nerd points.
Well said.
But: I have been using mu4e + Emacs for email for about two years now. I would seriously recommend anyone who already uses Emacs -- and especially if you use org-mode -- to look into it. Not because you score nerd points for reading & composing email in Emacs (frankly, you look ridiculous) but because it might just hook in perfectly with your workflow. I hardly touch any of the power user features, I do very little customization, and still it is by far the best way for me to manage my email. I also use it side by side with a web client (both Fastmail and Gmail) and switch if I need to.
I use emacs, but exclusively for orgmode. I thought about mutt years ago, and realized I get and receive too much mail with rich content for that to work.
How does an emacs window, even with mu4e, represent emails with meaningful formatting, inline graphics, etc? I'm guessing by launching an external viewer, but even that would slow me down quite a bit.
For basic formatting (bold text, headings, lists, links, etc etc), Emacs can render using its built in web browser. The "richer" it is, the more screwy the formatting gets. Usually you can at least read the emails.
You can easily pipe an email to your web browser of choice. This works fine but isn't exactly what you want to be doing all the time.
For my work, I am mostly dealing with plain text and attachments. The rich stuff is usually the email I care less about anyway. I don't think I'd want to use mu4e if I was dealing with rich content often. You can do it but it definitely slows you down.
People work in different ways. I live in emacs and am a humanities student, nobody sees my computer and I don't have a friend that can quit vi for his life, but I use the software that I use because it worjs the best for me. I have a very organised inbox, a good list of feeds, and a nice setup for org and orgexport. I can create jawdropping document with a quarter of the effort my peers spend to create a half arsed one in Word. I am on top of all thenews with asimple press of the G button in elfeed and 15 minutes readin, while my peers miss exams because nobodytold them. The only place I am behind is Facebook which I deliberately don't use. So no need for blanket dismissals.
While email has evolved from plain text to mostly HTML (apart from mailing lists), code still ist text only. Vim is a perfectly valid text editor and productivity in software engineering is not defined by how much your IDE can do.
> While email has evolved from plain text to mostly HTML
You must have a very different set of correspondents than I do. About the only non-bulk, non-plain text mail I get is when the office manager sticks a cute .gif in an announcement.
I use IntelliJ for coding and Emacs for mail (mu4e) and the combination seems to be good for me. Emacs is great for editing code, but for Java and SQL, IntelliJ does so much more.
The Mac mail app would be totally sufficient for me if it could handle complex searches over the volume of mail I have with speed, but it just doesn't. It helps that I'm in an organization with a disproportionate number of Linux users; I don't get any Outlook attachments or other Microsoft nonsense in my inbox.
The thing is an IDE can only do so much - depending solely on the IDE mean your ability to change/refactor the code is limited to exactly what the IDE gives you. If you need to do something that the IDE can't do for you then you're stuck. This is when being competent in Vim/Emacs/Shell is an advantage.
But you can extend IDEs just as well as you extend your vim/emacs. Not to mention, that for some users it's more convenient to hack extensions in Python (Sublime), Javascript/Coffee (Atom) or Typescript (vscode), rather than in weird dialect of lisp (lisp is cool, I encourage everyone to go and read SICP, but not elisp) or even worse, vim script.
Elisp is a good lisp. Certainly not the best, but quite workable, and very pleasing when the environment it's in is taken into account. Emacs is open source, has better apps than Sublime,not a web page like atom and not code centric like vs code. But maybe sublime and atom could provide a similar environment as they have the tools to create parallel ones. Butnothing like org and gnus exist elsewhere, unfortunately.
More generally, your window layout options in both are a lot more limited, and, worst of all, the extensibility experience in both is poor. Extensibility is basically non-existent in Xcode, and while it looks comprehensive in VS the APIs are rather unwieldy and underdocumented and the iteration time for testing is very bad.
Good extensibility support opens up many possibilities! Even with what VS gives you, you can get good stuff like Comment Reflower, or (if I say so myself) my VSScripts addin. But Emacs just does that side of things a lot better.
For example, multiple-cursors.el, which is an Emacs addon, is a huge improvement over the box selection available in VS/Xcode.
Adding reasonable support for a language to Emacs is easy to do in a couple of hours, possibly working from one of the many examples, and you can continue refining it from there. In VS by contrast options are the two extremes of "pretend it's one of the other languages VS supports already" (little better than Notepad with syntax highlighting) or "invest a week (plus) in writing an entire new language infrastructure, with no examples to work from" (I'm sure the results are good if you put the effort in though). For most under-supported languages you'll meet, Emacs is much closer to the effort/reward sweet spot.
(Xcode? I don't think you can make it support new languages at all.)
It's been a while since I used WebStorm (Javascript-oriented IDE) but my response to that was similar.
I've found every email client, mutt included, to be exceedingly difficult when trying to view your replies in the context of email thread. Gmail is the only one that does this seamlessly. If you get a ton of email, but never reply, or fire off so many replies that you never look back on them, maybe mutt works for you. For me the value of email and email clients is viewing the conversation as a thread, which importantly, must include my replies. You can find a few blog posts about configuring Mutt this way, it's complicated, convoluted, and always has side effects, like bcc'ing yourself. Outlook isn't all that much better in this regard as well, it does show your replies, but seems to loose them, or omit many from the thread.
Console based mail-clients are very powerful and fast to use. I was a long-time mutt user before I started writing my own mail client, with complete scripting provided by Lua.
Having a real scripting language allows a lot of useful features, at times using mutt felt a little bit too constrained, although it has a lot of features and is very very flexible in its own right:
The article seems to think that everyone should switch away from HTML. But how well does console clients deal with HTML emails. It's not like you can tell everyone to stop sending you HTML.
I use mutt as my sole email client and I don't find HTML to be that much of an issue. The vast majority of the emails I actually want to receive are either text or multipart/alternative with a text option. Now of course, depending on the type of email you receive your mileage may vary.
If I really end up having to read an HTML email those can be displayed "inline" using a text browser such as w3m. If the HTML is mostly text it works pretty well, for instance: https://svkt.org/~simias/mutt-html.png
If however it's image or css-heavy and doesn't work well in text-only form there's still the option to tell mutt to open the email in your web browser. Of course in this case there are security implications so it's probably best not to do it from untrusted sources.
Mutt deals surprisingly well with HTML emails. Most newsletters and other HTML mails usually come with a plain text version as well which Mutt will preferably display. Apart from that, you can make mutt pipe the HTML Email to a console browser for rendering. It works transparently. I've been doing this for a while now
What made me switched back to Mutt was the ability to call subapplications to show you emails. As I always have a browser running, I can tell mutt to show it in firefox, which allows me to watch the HTML mail in all of it's glory (instead of a lynx like dump in the console which I do not like).
I do exactly this too for the occasional mail that I really can't read as plain text.
One concern is that I'm letting through all web bugs and, perhaps, outright malicious HTML. If anyone has a solution for that, something like filtering the HTML, I'd love to hear it.
The general approach is to display the text/plain version of any incoming mails, but if you absolutely need to view the HTML then you'll pipe out to lynx, w3m, or links to view it.
I suppose that mutt could be configured to either display the plain text MIME part of such an email, or pipe the HTML through something like links -dump.
I'm guilty of the Lua feature, and even though it's only covering the existing muttrc API, it can already do quite a lot. The Lua feature is (not yet) turned on by default at compile time (and thus in systems distributions).
I'd be very happy to have more feedback and help to extend further that API and have some great scripts happening!
I think the point where Lua gets interesting is when it can be invoked when a new message is received, or you can iterate over message heads & the message-list(s) and process them automatically.
For example you might have a folder of "backup results", you'd want to mark all that have a subject of "Backup OK" as read, and flag the ones that have a subject of "Backup FAILED" as "important". Those are the kind of tasks I automate with my lua-based mail-client.
You can get more interesting and say "Keep only the most recent 100 messages in folder XXX" which applies whenever you either launch the client, or open a given folder too.
I found neomutt and find it to be nice. One thing that's been annoying me in mutt is that there is no unified inbox. Neomutt integrates notmuch as a first class citizen along with some other niceties(amongst others basic lua scripting).
When I was using mutt, one of the biggest things that I found missing was a way to apply a filter to the entire email without creating some sort of SMTP gateway. I wanted the ability to compose my emails in Markdown, and run the text/plain version through a filter to generate a text/html version. At the time (though I'm sure this hasn't changed), you could only run various parts of the email (e.g. only the text/plain part) through filters, but not the whole email.
I used some good emacs mail client up to 1995, then the need to read Office attachments made me switch to some Windows client. HTML messages were not a thing yet. The switch was a regression in functionality for at least ten years, up to outbound filters in Thunderbird.
Edit: third question, how do you read mail on your phone?
A couple of questions for the author. How do you handle attachments and do you download mail over POP3/IMAP or do you have your own server (hence SpamAssassin) ?
One of Mutt's best uses cases in my opinion is for rapid processing of lots of email.
Every now and then I'll go on a spree to zero out my inbox, and I find doing this with mutt's search/tag/move/delete workflow is a lot faster than messing around with my mail provider's application (Fastmail's, which is awesome, and Gmail's, which is less so) or any other client I'm aware of.
I switched back to mutt 5 months ago, when my startup started to grow fast and I needed a sensible way to deal with lots of email in multiple accounts. I haven't looked back. I still have gmail as a back-end, but I use mbsync to keep local copies of all my accounts, and msmtp to send mail.
I used mutt for 10 years and then moved back to web mail. With inbox zero and gmail keyboard shortcuts, processing email is so easy that mutt is almost an over-kill.
I use alot (to view and send mail) + notmuch (to index) + mbsync/isync (to retrieve mail). It was painful to configure, mostly due to needing scripts for syncing up tags with IMAP folders.
So far its been worth it. Instantaneous search of all my email ever. With a properly configured mailcap file HTML emails are rendered ok (still have problems with links) and attachments open in external programs as well.
Since `alot` is written in Python and can be extended with Python hooks for almost any event it has been easier for me to customize than emacs.
Same here. I ended up writing a wrapper for alot (and a custom MDA): https://github.com/jakeogh/gpgmda (just split the client stuff into gpgmda-client, see the client side deps list)
I've been using mutt + vim + gpg + multiple gmail account for the last ~5 years and it's proven to be fast and easy to use, the only issue I have is that it disconnect from time to time from the imap servers.
I'm late to this conversation: happy to see such a robust discussion on mutt, but sad to see so many hardcore techies preferring gmail instead. To each their own, of course, but mutt is one of the things I love most about *nix platforms. I've got a chromebox that requires I use webmail (the Fastmail web client is really, good actually) but elsewhere, mutt is the only way I can handle email.
To the comment about mutt's poor addressbook support, you can use it with a CLI/CUI app called addressbook that's quite good, and you can interface with with other addressbook scripts to access carddav servers as well. I'm intrigued by the links to carddav support.
For me, the HTML email and calendar invite issues are trivial, and grossly outweighed by the efficiency I get with mutt by being able to select and act on huge amounts of mail at once. The threaded view is essential. In a pinch, I use sylpheed/claws or even Thunderbird. But after using mutt at home, going to work where I'm forced to use Outlook makes me want to claw my eyes out: in my opinion, Outlook has gotten worse every year, and is barely useable at this point.
Meanwhile in mutt, I can do things like "delete every message between dates X and Y and sent by person Z." It makes dealing with huge amounts of mail effortless. I also tire of editors, and cycle repeatedly through emacs, vim, slrn, and joe/jstar/jmacs - I love the flexibility. I combine it with Fastmail/IMAP, and wouldn't dream of going anywhere else. Gmail isn't for me: if it works for a lot of you, congrats - I'm past the point where I care about converting others to what I consider "the one true way." Just wanted to add to the conversation my opinion that the day they I can't use mutt for email is the day I stop emailing, period.
Funny. Several years ago I went in the opposite direction: From mutt to notmuch + emacs.
I used mutt for about a decade. I got sick of it being a bit too constraining (e.g. could not auto-Fcc to multiple folders based on To fields). And frankly, for the last 5 years of my usage, there was no real development.
notmuch is great for me. Using tags and Python, filtering incoming mail is a lot easier than with procmail's arcane syntax. I've recently set up a whitelist email system to get rid of unwanted emails. If a "new" person emails me, they get sent to a web site to confirm their identity and their email gets put into a quarantine folder (not inbox). If they go to the web site and confirm, then my mail system moves their email from quarantine to the inbox and their email address is whitelisted.
No more junk mail. The only mails that get to my inbox are from whitelisted accounts.
Notmuch with tags made this a trivial thing to code.
I love mutt and tin (Network News, google it youngsters), and I persisted in sending plain text email for many years, even signed it with pgp. I snickered many times over the years as people got hacked by their own email clients. I sent back 'Meeting Invite' emails to people who couldn't draft a proper meeting request using words.
But ultimately when gmail came along I realised there was a better way. It is only a problem that we give up our privacy and agency by using Google's software and computers. And nobody was checking my PGP signatures anyway.
If you feel like you want to get the benefits of a nice email GUI, in a sandboxed browser, but also want privacy and some control, check out Mailpile:
I already use enough arcane tools on a daily basis due to my work. For mundane stuff like reading and sending mail, I'd rather take a break and use tools that even my tech illiterate father could effectively use.
It's really detoxicating to become a normie from time to time.
Disclaimer: Used to read mail with emacs back in the day. Tried mutt for a while.
This kind of attitude is not helpful. Sometimes even tech people want things that work "good enough" with no configuration or thinking involved. No need to go full normie.
I'm not trying to be helpful. But I find this worry about having to configure CLI tools to be overstated. Just because they allow you to configure everything doesn't mean you have to. My personal email setup is: "sudo apt install alpine", configure account info, done.
You don't even have to memorize the action keys, Alpine shows the available actions for the current screen at the bottom, with helpful labels. It's arguably clearer than Gmail, with its unlabeled icons.
Sadly thats not the norm. A lot of those (otherwise great) text tools ship with horrible defaults and suffer from poor discoverability. Sometimes it's both combined and somebody actually contributed such an improvement but nobody bothered to turn it on.
Format=flowed is great. I just wish more clients supported it—for sending and receiving. I've felt lately that I would even consider using the Windows Mail app if it supported plaintext and f=f.
Very good. I could easily complement this with a calendar terminal app. Anyone knows of a terminal calendar app to keep appointments ? (similar to the apple calendar, or google calendar)
I switched to mutt .. about a dozen years ago, from PINE. I still use it with a pine keybindings file, and I still miss the better addressbook support of pine.
Mind you, that's on a secondary email account; if I need to handle images or attachments I forward it to gmail.
I have been using mu4e for three years or so and not had any bugs or glitches to speak of. I haven't experienced any stability issues with package upgrades either.
I started using emacs for email back in my uni days. I used Dovecot to run an IMAP server locally which would get my mail when it could. This made it very quick in emacs because it wouldn't have to wait for any remote server.
But, unfortunately, I had to go back to Thunderbird. With the exception of free software mailing lists, people simply do not know how to use email. Bottom quoting is the default. We can thank Microsoft for that one, I think. I can't understand why anyone thought it was a good idea to attach the previous message to the bottom. Most people just accept this as the way email is and never question how unbelievably stupid it is.
Then you've got all the HTML shit that people put in there. And the fact that many clients are simply broken and don't write the headers correctly which breaks threading. This is often confounded by broken servers which garble the headers a second time.
It's amazing that something as simple as mutt or gnus (emacs) has everything you need: threaded messaging and convenient composition. Inline quoting is surely the only sane way to do quoting. Why would you assume the person you reply to has deleted their own message? My message to you is right there in the same thread in my client. Don't send it back to me. But do make it clear which parts of it you are addressing (inline quoting). You had to laugh when Google reinvented threaded messaging in the 2000s and advertised it as some groundbreaking new thing.
So I gave up. I use a client that can deal with the stupid shit that other clients spit out. I also bottom quote now. Why? Because if you do inline quoting, MS Outhouse web client thinks that everything after the beginning of the quotation is a copy of the previous message and folds the whole thing, meaning your recipients get back what looks like an empty message. Really.
> My message to you is right there in the same thread in my client. Don't send it back to me.
Dozens of times a day I add someone to the cc list when I'm replying to an email. I suspect most people that have an assistant (or are one, or collaborate with others in general) do this constantly.
It's an incredibly common use case. Should we all abandon this very common behavior in order to avoid your scorn?
I don't think that copying an entire email thread to someone is an effective way of communicating. It's just a way to cover your ass. If you try to choose your words carefully and explain the situation to your recipient, then you have to take some responsibility for their understanding. If you just copy them the 200 prior emails, you've "done your job." The responsibility to understand is now theirs.
This is a great strategy for protecting yourself in business, but it makes everything slower and more difficult for everyone else.
With inline quoting the relevant content of the conversation is immediately and easily discernible. You may Cc people with a whole copy of the thread, but IME nobody bothers reading through. For one thing, it's in reverse order so very difficult to follow.
OTOH, inline quoting was always destined to fail. It requires that you purposefully and carefully edit and reply in the appropriate places. That's asking too much of the vast majority of people. B
With inline quoting the relevant content of the conversation is immediately and easily discernible. You may Cc people with a whole copy of the thread at the bottom, but IME nobody bothers reading through. For one thing, it's in reverse order so very difficult to follow. It will also contain all the irrelevant parts of the discussion, which in a long thread will be the vast majority of the quote, thus making it even more burdensome to wade through. Part-and-parcel of inline quoting is pruning.
OTOH, inline quoting was always destined to fail. It requires that one purposefully and carefully edit the thread and reply in the appropriate place. That's asking too much of the vast majority of people. Perhaps it could have been preserved to a greater extent had Microsoft Outlook not effectively forced bottom quoting, but alas that ship sailed decades ago.
--
A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?
A: Top-posting.
Q: What is the most annoying thing on usenet and in email?
> Dozens of times a day I add someone to the cc list
Incidentally, your daily dosage coincides with the amount of times I've had to do the same thing at all since I started using email some twenty five years ago.
> It's an incredibly common use case
For some, perhaps. On the other hand, I'd suggest that another, at least for me more common use case is to know exactly what is being replied to. Which is possible with proper quoting, rather than the let's-just-slap-on-your-entire-message-at-the-bottom-and-hope-you're-a-mind-reader nonsense.
1) Hi there I have a request for a meeting or phone call, or need something from your organization.
2) Great, I'm copying my assistant who will schedule this, or the other person in the company who knows the answer to your question, who I have now handed this task off to nearly instantly and seamlessly.
if you do inline quoting, MS Outhouse web client thinks that everything after the beginning of the quotation is a copy of the previous message and folds the whole thing, meaning your recipients get back what looks like an empty message. Really.
Gah; that explains it. Occasionally I get a reply saying "you just sent me a blank email", while the text of my email is quoted right there in the email they've just sent me!
That was my response 15 years ago. Unfortunately, I've lost that battle and moved on. There comes a point when trying to fight the common expectation leads to zero return.
(And yes, I miss the days where SMTP & NNTP servers would actually enforce the ratio of non-quoted lines vs. quotes lines, forcing users to trim the relevant parts of the message they are replying to.)
I used to try this. Imagine being the only person using some weird text based thing instead of just simply using "email" (ie. logging on to webmail). Remember there is a huge number of people who have not used anything but webmail (like gmail).
> With the exception of free software mailing lists, people simply do not know how to use email. Bottom quoting is the default. We can thank Microsoft for that one, I think. I can't understand why anyone thought it was a good idea to attach the previous message to the bottom. Most people just accept this as the way email is and never question how unbelievably stupid it is.
I think a lot of email clients expect that type of quoting/top-posting (conversation view for example). Another problem is that certain mobile email clients make it impossible to not bottom-quote. That is, they just present a composition window and don't give you the ability to position your text within the quoted email you're responding to.
Though I do find it interesting that people on Hacker news, Slashdot, and reddit will generally follow the convention of responding inline if they quote the parent post in their response. I don't recall anyone ever following the email "convention" of bottom-quoting.
> Though I do find it interesting that people on Hacker news, Slashdot, and reddit will generally follow the convention of responding inline
Actually, they don't. Most posts don't quote their parent at all, it's a unitary response to the full parent post. Which is what bottom-quoting does - it doesn't actually quote the parent post, it leaves it in for reference (which makes sense because email clients, unlike HN, are pretty crap at keeping track of conversation threads).
Very few people communicate in the super-structured way that in-line quoting implies, that you go through an email sentence(/line/paragraph) by sentence(/..) and respond individually to them. It's super-arrogant, and thankfully getting very rare, to insist that your way, just because it was first, and then completely failed to catch on, is the one true way and people are "unbelievably stupid" to disagree with you.
>> Though I do find it interesting that people on Hacker news, Slashdot, and reddit will generally follow the convention of responding inline if they quote the parent post in their response.
> Actually, they don't. Most posts don't quote their parent at all
I never said that most people do. When you quoted my post in your response, you left off the clause where I said: "if they quote the parent post in their response".
> It's super-arrogant, and thankfully getting very rare, to insist that your way, just because it was first, and then completely failed to catch on, is the one true way and people are "unbelievably stupid" to disagree with you.
This aptly demonstrates that there value quoting the relevant parts of the post you're responding to. In this case, you're attributing statements that someone else made to me. If you want to argue against what you're quoting, then you should reply to the post that actually made those statements.
Bottom quoting means you read the answer before the question, breaking the logical flow of conversation. Not trimming means the messages have a vast amount of text to skip over each time.
The beauty of inline quoting is that if you don't see a need to use it then you don't. It is in no way arrogant to suggest a method of replying which is unambiguous. Nobody is suggesting that it is used in places in which it is not necessary.
I hate to think of the hours wasted due to ambiguity in email replies. More often than not people end up using the telephone or meeting in person which wastes even more time rather than learning how to be clear. I don't understand why all effort to be clear and precise goes out of the window when dealing with email.
Though HN doesn't make it easy to do inline quoting. I tried it just now, only to have my nicely formatted text block overflow due to the browser's text area idiosyncrasies.
Most people actually don't quote at all. It's just that the majority of mail clients out there, including the Web ones, quote the message being replied to and position the cursor above it, and no one takes the effort reformat it, or remove it.
Software needs to make it easy to choose portions of the message and automatically quote them in replies. Currently the usability of that aspect is broken. You have to cut and paste manually. A lot of messaging systems don't even add '>' marks.
> Though HN doesn't make it easy to do inline quoting. I tried it just now, only to have my nicely formatted text block overflow due to the browser's text area idiosyncrasies.
On HN, this is handled entirely by wetware - there's an unofficial convention. You quote the relevant part of a post by preceding it with '>' (but not turning it into a text area!). Many people (myself included) also italicize part after the '>' to make it more visually different from their response.
MS Outhouse? Really? Are you a 13 year old boy in 2003? Your message shows that you've never used email in a corporate setting, where people cc other people (who will need copies of the previous correspondence) all the time, and people might take you more seriously if you leave out the Micro$oft 'jokes'.
I agree, it's a losing battle. Such a shame. I have one or two friends who quote inline, and I love getting emails from them. They look so clean and readable. But it's pointless trying to do it with most people because most people don't reply with inline quotes and just top post and it ends up as a godawful mess. So I barely even bother any more myself. I die a little every time.
> I used Dovecot to run an IMAP server locally which would get my mail when it could. This made it very quick in emacs because it wouldn't have to wait for any remote server.
I do a similar thing, but using mbsync to save into maildir. That way it's a simple cron job/systemd service to do the fetching, and Emacs/mutt/whatever can read the data without needing a server process to be running.
I used to use Gnus, but since it does everything in elisp it makes Emacs freeze :(
I now use mu4e, which uses an external command (mu) to query the maildir, so emacs remains responsive. My mail-fetching script also runs mu after mbsync's finished, to index any new messages.
> I can't understand why anyone thought it was a good idea to attach the previous message to the bottom. Most people just accept this as the way email is and never question how unbelievably stupid it is.
In addition to the obvious idiocy of sending someone a copy of what they just sent you ... I think it's funny to realize how this behaviour actually has quadratic space and bandwidth complexity:
If a thread is 10 message long, you have to store and transmit the data of 55 messages.
If a thread is 100 message long, you have to store and transmit the data of 5050 messages.
Or in general, if a thread is n message long, you have to store and transmit the data of n*(n+1)/2 messages.
And with Outlook, if you have a large TO or CC field that gets included at the top of the quoted message. Some dopes started reply-all chain at work a year or two back. After 3 or 4 messages it was a several MB message being sent to 1000 people.
I'm surprised no one has mentioned MH-E. I've used it continuously since the 80's. About 15 years ago it got multipart MIME support, which has improved every year. I can handle attachments like a boss. I even wrote a filtering system that sits on top of it (a replacement for the inc program that sorts into different inboxes).
> My message to you is right there in the same thread in my client. Don't send it back to me.
I do inline replies and all, but I still leave the quoted rest of the thread at the end of the message. If the recipient doesn't need it, they are free to ignore it. If the recipient needs it, then it's there. Many people don't use threaded email clients, or don't have access to the previous messages for whatever reason, and I don't want to second-guess how my recipient does things.
As long as it's clear where my reply ends and that there's nothing hidden at the end of the quoted previous messages, I really don't see the harm.
(About bandwidth or storage costs: they are negligible, and I do not think it is a good usage of time to worry about them.)
Long-time internet tradition has the replies going inline with the quoted message, with judicious trimming of irrelevant bits. It's frustrating that this has to be explained in the modern world. Smart young developers exist who have literally never seen a discussion that works that way.
For most messaging in larger organisations, having "paper trail"-style replies that you can forward to others has its advantages -- it better delimits in a single page who said what, and when.
If I know my conversation is intended to a small group I'll reply inline, but my default is quote-on-top.
There is a MIME type for emails, so you can attach emails to emails, retaining their identity as emails, so the receiving MUA can display the emails you receive as an attachment just like any other emails, including the user interface for replying to them, or whatever.
Also, there is threading information in email headers. So, it is actually trivial to just gather together all the emails belonging to a specific conversation and attaching them all to an email to a third party that needs the history.
Using this bottom full quote nonsense is about as sensible as attaching a screen shot of a word document or something.
While arguably it's Gmail's fault, there are email clients, such as Gmail, that do not behave well with, or perhaps support at all, emails as attachments. When emailing people who use Gmail (as personal email or as the host of their work email), sending emails as attachments just doesn't work well.
Well, yeah, sure, there is terrible software out there. But if you expect everyone you communicate with to live with terrible usability because you insist on using broken software, then you are just being an asshole. Email is an open, federated system, you can just switch to different client software.
> For most messaging in larger organisations, having "paper trail"-style replies that you can forward to others has its advantages
That brings up another point about using email for group conversations. If organizations hosted their own NNTP servers and commonly installed email clients also supported communication via NNTP, then this wouldn't be a problem. All messages already posted to a group would be visible to anyone who joins it at a later time. That's not the case with an email discussion that gets Cc'd to someone at a later time (since they don't have any of the earlier messages in their mailbox).
Has any organization (Fortune 500-style company) ever, in the history of the world, hosted its own NNTP server and expected employees to use it for communication? My guess is absolutely not.
I suspect yes, because Lotus Notes was briefly very fashionable for corporate communication, and apparently supported NNTP, according to this article (PC Magazine, 24 Feb 1998):
Oh sure. The "mailing list" style presumes some archive exists where you can find the missing context. I'm not taking sides here (much), I'm just remarking how weird it is that kids today never even see the old style.
I've been using multiple IMAP and SMTP accounts in Alpine for years, the setup works nicely.
I've had some issues with how Alpine handles connection time outs though, as it annoyingly blocks the UI from time to time. Need to look further into this...
I switched to mutt after I was unable to view images with emacs (gnus) as it did not bother (or failed) to un-base64 them before either trying to display them in-line nor when saving the image.
Integrating mail with Emacs was the best idea ever, because Emails include either todos or serve as reference in projects. Creating todos from Mails as well as linking to them from org-mode is only a shortcut away.
I have never had a more easy to manage and productive todo management system - and it's all text, so there will never be breaking changes or paid upgrades or incompatibilities between tools that I cannot fix.