Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching to the Mutt Email Client

nullprogram.com

Post reply on HN
Print view View original

81–90 of 246 posts

Re: Switching to the Mutt Email Client

#81

Post by ziotom78 »

MikeTaylor wrote: post #21

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.

Re: Switching to the Mutt Email Client

#82

Post by dotancohen »

tambourine_man wrote: post #70
curiousGambler wrote: post #69

Earlier quoted context omitted.

This is one of two honest answers to this question, thank you. (The other is "I'm old enough to have been using text email since before graphical email clients were a thing and don't want to change.")

There's also another. Navigating TUI with Vim key bindings is very fast

> 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

Re: Switching to the Mutt Email Client

#83

Post by Samon »

oblio wrote: post #15

I feel that the folks that do this aren't working for big companies. In most big companies you can't really afford to do any email client shenanigans. You probably need to see HTML emails, handle calendar invites, etc.

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.

Re: Switching to the Mutt Email Client

#85

Post by nazri1 »

szastupov wrote: post #78

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.

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.

Re: Switching to the Mutt Email Client

#88

Post by Longhanks »

szastupov wrote: post #78

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.

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.

Re: Switching to the Mutt Email Client

#89

Post by pleasecalllater »

nazri1 wrote: post #85
szastupov wrote: post #78

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.

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.

Could you tell me what was the last problem you had that an IDE couldn't do, and vim/emacs could?

Re: Switching to the Mutt Email Client

#90

Post by dcousens »

pleasecalllater wrote: post #89
nazri1 wrote: post #85

Earlier quoted context omitted.

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.

Could you tell me what was the last problem you had that an IDE couldn't do, and vim/emacs could?

Easy. Vim doesn't get in my way.
Post reply on HN