8 ms·

I haven't dug too deep into the features or how this works yet, but it's very exciting to see any kind of movement in this space at all. I've spent a lot of tim

by rlue 7y ago

I haven't dug too deep into the features or how this works yet, but it's very exciting to see any kind of movement in this space at all. I've spent a lot of time configuring mutt just the way I like it, but I'd throw it all away in a heartbeat for a good, modern alternative. My wishlist: * A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. (I know mutt has an IMAP mode, and it looks like that's aerc's primary mode of operation, too, but I like to have a local copy of my entire mail archive.) * Rendering plain text markdown into multipart/html emails. I love me some plaintext, but no one else in my life even knows what a terminal is. 80-char lines are too short for desktop displays and too long for small phones (leading to awful linebreaks), which makes me the guy whose emails never look right.

stevekemp 7y ago
I came up with my own mutt-alike, written with Lua for real scripting. Sadly it seems these projects are pretty niche, they're also damn hard to write. I spent a lot of time fighting with malformed MIME messages, etc. Then adding on GPG-support, and handling the UI, all becomes a huge time-sync. Still I now have a client that I love, even if nobody else does! https://lumail.org/ https://lumail.org/
- tonyarkles 7y ago
  > malformed MIME My god. I tried parsing my gmail “All Messages” once as part of a project. It ended up being an amazing corpus of a zillion ways to do MIME wrong. Project didn’t get off the ground because even after handling all of my weird cases, every new user ended up blowing up the parser again. Yeesh.
- marmaduke 7y ago
  Doesn’t claws have a reusable library for that sort of thing?
u801e 7y ago
> 80-char lines are too short for desktop displays and too long for small phones (leading to awful linebreaks), which makes me the guy whose emails never look right. RFC 3676 [1] describes the format MIME parameter for text/plain content type documents which solves this issue. Unfortunately, it does not work well when sending inline patches via email since it introduces trailing whitespace. [1] https://www.ietf.org/rfc/rfc3676.txt https://www.ietf.org/rfc/rfc3676.txt
- JoshTriplett 7y ago
  format=flowed has many other problems, aside from mangling mails. It gets lost easily; intermixing mail clients that handle it with those that don't (or have been intentionally configured to ignore it because it mangles mails) produces poor results; it often breaks signatures; it makes it harder to quote and reply to emails; in general, it means the person on the other end will not see exactly what you sent.
  - chrismorgan 7y ago
    Also potentially interesting to people that like the idea of format=flowed, an bit of an explanation of why FastMail doesn’t support it: https://fastmail.blog/2016/12/17/format-flowed/ https://fastmail.blog/2016/12/17/format-flowed/
  - babuskov 7y ago
    Thus the nickname: format=flawed
  - u801e 7y ago
    > It gets lost easily; How, unless the MUA is modifying quoted text beyond prefixing each line with >. > intermixing mail clients that handle it with those that don't (or have been intentionally configured to ignore it because it mangles mails) produces poor results I participated in many lengthy discussions in deeply nested threads on usenet with an email client (Thunderbird) that had format=flowed enabled for the text/plain posts that I was sending. I never noticed any issues when viewing posts I made or other posts that were descendants of my posts. That is, no problems with line wrap or other rendering issues (either when looking at it in Thunderbird's view pane or looking at the raw message text). > it often breaks signatures; It shouldn't break them if the client applies the signature itself. > it makes it harder to quote and reply to emails I don't see how this would be the case. When you reply to an email, the MUA should prefix each line in the body of the original message with a > character. Whether those lines have a single trailing whitespace character or not shouldn't make a difference in terms of quoting the original text. > it means the person on the other end will not see exactly what you sent. Unless you have text that requires wrapping at specific line lengths, they will see what you sent. If their client supports the flowed format, the lines will be rewrapped to your screen width. If their client does not, then they see the original raw text with trailing whitespace at the end of each line (other than the last line of each paragraph) which essentially is not visible to the reader unless they've configured their client to display a marker for trailing whitespace.
hdfbdtbcdg 7y ago
Checkout offlineimap. Mutt can then use the synched directory from offlineimap.
- masklinn 7y ago
  offlineimap is cron-driven though, so it doesn't fetch mail "as soon as it arrives". I don't know that any offline-sync daemons uses IDLE though. isync / mbsync doesn't seem to either.
  - cbcoutinho 7y ago
    I use a systemd timer to handle periodic calls to offlineimap, and that works really well compared to a corn-based work flow.
    - masklinn 7y ago
      systemd timers are a cron-based workflow. A cron-based workflow is when you periodically check for work to do rather than get notified that there's work to do.
      - cbcoutinho 7y ago
        Yes that's true that they periodically check for work to do, but cron is not smart enough to know whether a service is already running - a systemd-timer can base it's timer from the point when a service completes. I think cron just fires up a service unless you build in some logic to check if it's running
        JdeBP 7y ago
        That's not really relevant. masklinn is contrasting periodic polling schemes like yours with using IDLE.
  - naniwaduni 7y ago
    offlineimap does have IDLE support. It's known to exhibit hard-to-reproduce bugs, though.
BeetleB 7y ago
>A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. (I know mutt has an IMAP mode, and it looks like that's aerc's primary mode of operation, too, but I like to have a local copy of my entire mail archive.) What's wrong with fetchmail? Granted, it's not "as soon as it arrives", but you can run it every minute if you want.
- def- 7y ago
  You can use -d <interval> to run fetchmail in daemon mode and then use --idle so that the server can push messages to you immediately. (I also use unison to keep the mail directory synchronized between all my machines.)
- Jaruzel 7y ago
  These days, a lot of services with 2FA type emails or validation emails expect you to receive them within seconds. Also, how many times have you spoken to someone on the phone for them to say "I've just sent you the details.... can you see it yet?"
  - codethief 7y ago
    > These days, a lot of services with 2FA type emails or validation emails expect you to receive them within seconds. Within seconds, really? I haven't encountered a single service like that. > Also, how many times have you spoken to someone on the phone for them to say "I've just sent you the details.... can you see it yet?" True but there's an easy solution: Fire up a terminal or even use a keyboard shortcut to run offlineimap manually within a split second.
    - pjc50 7y ago
      Well, you can't log in until you recieve the email. I've had a variant of this due to using a custom domain with a small email provider that was either slow or greylisting; the second-factor login email for GOG took longer than 15 minutes to arrive, by which time it had expired. I had to keep trying until it came through quickly enough.
coldtea 7y ago
>80-char lines are too short for desktop displays Nothing makes them "too short for desktop displays". Text is not supposed to fill all/most of the available display width: “Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line(counting both letters and spaces) is widely regarded as ideal.” -- The Elements of Typographic Style Applied to the Web
- mrzool 7y ago
  > Text is not supposed to fill all/most of the available display width That is pretty obvious, but every modern email client is able to deal with text wrapping itself. The only effect of the 80-char limit today is that of butchering your emails, especially on mobile. Since format=flowed is not supported enough, the only solution here is HTML.
  - dmos62 7y ago
    Seconded, this kind of formatting shouldn't be hardcoded in the email. For me ideally, the presentation would be specified in the clients and it wouldn't be part of the message. Provided all emails are prose-like, which they are in my case.
- tssva 7y ago
  "The Elements of Typographic Style Applied to the Web" was originally released in 2005 and I'm afraid some of the advice may be stuck there. This advice being among that advice. In 2005 many displays were still 4:3 ratio and this advice more applicable. With modern 16:9 ratio screens 66 character line lengths can seem extremely short and require unnecessary vertical scrolling to view a message with such line length. I find it quite visually jarring to receive an email with a fixed width that wastes the horizontal space of the viewing window. Instead of being fixed width the text should be reflowed to properly fill the viewing window.
  - sagichmal 7y ago
    The optimal width of a column of text is not a function of the container it is in, or the screen it is displayed on, but rather a constant based on the capacities of human vision. It's roughly empirically accepted that it's easier for us to read a block of text that flows from one line to the next after approximately 65-85 characters. Thus that extra space on the margins isn't wasted, it's serving an important purpose.
mrzool 7y ago
> Rendering plain text markdown into multipart/html emails. [...] 80-char lines are too short for desktop displays and too long for small phones (leading to awful linebreaks), which makes me the guy whose emails never look right. I completely agree! That's exactly the feature I requested, for exactly the same reasons, to the developers of Neomutt. I was pleasantly surprised when it turned out they were open to the idea. They got it implemented eventually. The discussion is here: https://github.com/neomutt/neomutt/issues/587 https://github.com/neomutt/neomutt/issues/587
pwg 7y ago
> 80-char lines are too short for desktop displays and too long for small phones What you want is format=flowed emails. Check the mutt manual (http://www.mutt.org/doc/manual.txt http://www.mutt.org/doc/manual.txt for format=flowed and this blog post (https://brianbuccola.com/line-breaks-in-mutt-and-vim/ https://brianbuccola.com/line-breaks-in-mutt-and-vim/). And for details on format=flowed, read here: https://joeclark.org/ffaq.html https://joeclark.org/ffaq.html
- mrzool 7y ago
  It would be great if it was so easy. Sadly it’s not, because format=flowed is ignored by many email clients. See also: https://github.com/neomutt/neomutt/issues/587 https://github.com/neomutt/neomutt/issues/587 Also this article: https://fastmail.blog/2016/12/17/format-flowed/ https://fastmail.blog/2016/12/17/format-flowed/ The only solution is HTML and multipart emails. Edit: added link to article
- nextos 7y ago
  I've given up on format=flowed because if you are not really careful to insert hard newlines, it can break inline attachments. In fact, hardcore users of plain text email like LKML discourage it for this reason. That said, it's nice to see a new text-oriented mail client. I remain skeptical about Unix interactive text-mode applications, though. Unlike classical Unix tools, more complex interactive applications do not compose well. They are little silos. I was a long term Mutt user, but I eventually moved my email into Emacs. That was because Emacs applications feel part of a consistent environment, a text-mode Lisp VM. They can easily talk to each other, and you can extend them beyond their designers ideas. On Mutt on the other hand, any non-trivial extension was just a pile of hacks. For example, multiple accounts. I encourage HN users to take a look at Notmuch, both as a MUA inside Emacs or elsewhere, it has a really nice architecture. It's kind of a side-effect free mail user agent.
wazoox 7y ago
> A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. fetchmail + procmail do just that. Use the Unix way :)
nulbyte 7y ago
> * A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. You can do this with fetchmail and procmail.[1] [1] http://www.ioncannon.net/system-administration/97/using-fetchmail-and-procmail-for-maildir-style-storage-from-a-pop3-account/ http://www.ioncannon.net/system-administration/97/using-fetc...
zeveb 7y ago
> A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. I've used both OfflineIMAP & mbsync for this; I'd recommend the latter these days. Works great. > Rendering plain text markdown into multipart/html emails. I have a feeling you could do something with emacs & one of its mail modes to do this, by slapping something into a hook … Ah, this guys looks to have come up with a way: https://ioctl.it/posts/2015-03-18-emacs-html-mail.html/ https://ioctl.it/posts/2015-03-18-emacs-html-mail.html/
masukomi 7y ago
Markdown -> HTML without killing the ability for text clients like the one I was using was a must have before I would switch to (neo)mutt. Here's how I managed to do it. text/plain (markdown) -> multipart/alternative with neomutt macro compose K "| pandoc -f markdown -o /tmp/neomutt-alternative.html<enter><attach-file>/tmp/neomutt-alternative.html<enter><tag-entry><previous-entry><tag-entry><group-alternatives>"
chme 7y ago
I am currently a bit unhappy with html rendering on the terminal as well, but for another reason: Links What I would wish for is some way to render the html link text as well as the address in the terminal, so that I can easily open those in a browser. I have looked into a way to convince w3m to do that, but haven't found one yet.
- Fnoord 7y ago
  Try Browsh, it is Firefox for the terminal.
- megous 7y ago
  The only workable solution (with mutt) so far is to have a program bound to a key to extract the links and allow you to select one of them and open it via xdg-open.
amiga_500 7y ago
offlineimap does this, write to Maildir then have mutt use this.

by rlue 7y ago

stevekemp 7y ago

I came up with my own mutt-alike, written with Lua for real scripting. Sadly it seems these projects are pretty niche, they're also damn hard to write. I spent a lot of time fighting with malformed MIME messages, etc. Then adding on GPG-support, and handling the UI, all becomes a huge time-sync. Still I now have a client that I love, even if nobody else does! https://lumail.org/ https://lumail.org/

tonyarkles 7y ago
> malformed MIME My god. I tried parsing my gmail “All Messages” once as part of a project. It ended up being an amazing corpus of a zillion ways to do MIME wrong. Project didn’t get off the ground because even after handling all of my weird cases, every new user ended up blowing up the parser again. Yeesh.
marmaduke 7y ago
Doesn’t claws have a reusable library for that sort of thing?

u801e 7y ago

> 80-char lines are too short for desktop displays and too long for small phones (leading to awful linebreaks), which makes me the guy whose emails never look right. RFC 3676 [1] describes the format MIME parameter for text/plain content type documents which solves this issue. Unfortunately, it does not work well when sending inline patches via email since it introduces trailing whitespace. [1] https://www.ietf.org/rfc/rfc3676.txt https://www.ietf.org/rfc/rfc3676.txt

JoshTriplett 7y ago
format=flowed has many other problems, aside from mangling mails. It gets lost easily; intermixing mail clients that handle it with those that don't (or have been intentionally configured to ignore it because it mangles mails) produces poor results; it often breaks signatures; it makes it harder to quote and reply to emails; in general, it means the person on the other end will not see exactly what you sent.
- chrismorgan 7y ago
  Also potentially interesting to people that like the idea of format=flowed, an bit of an explanation of why FastMail doesn’t support it: https://fastmail.blog/2016/12/17/format-flowed/ https://fastmail.blog/2016/12/17/format-flowed/
- babuskov 7y ago
  Thus the nickname: format=flawed
- u801e 7y ago
  > It gets lost easily; How, unless the MUA is modifying quoted text beyond prefixing each line with >. > intermixing mail clients that handle it with those that don't (or have been intentionally configured to ignore it because it mangles mails) produces poor results I participated in many lengthy discussions in deeply nested threads on usenet with an email client (Thunderbird) that had format=flowed enabled for the text/plain posts that I was sending. I never noticed any issues when viewing posts I made or other posts that were descendants of my posts. That is, no problems with line wrap or other rendering issues (either when looking at it in Thunderbird's view pane or looking at the raw message text). > it often breaks signatures; It shouldn't break them if the client applies the signature itself. > it makes it harder to quote and reply to emails I don't see how this would be the case. When you reply to an email, the MUA should prefix each line in the body of the original message with a > character. Whether those lines have a single trailing whitespace character or not shouldn't make a difference in terms of quoting the original text. > it means the person on the other end will not see exactly what you sent. Unless you have text that requires wrapping at specific line lengths, they will see what you sent. If their client supports the flowed format, the lines will be rewrapped to your screen width. If their client does not, then they see the original raw text with trailing whitespace at the end of each line (other than the last line of each paragraph) which essentially is not visible to the reader unless they've configured their client to display a marker for trailing whitespace.

hdfbdtbcdg 7y ago

Checkout offlineimap. Mutt can then use the synched directory from offlineimap.

masklinn 7y ago
offlineimap is cron-driven though, so it doesn't fetch mail "as soon as it arrives". I don't know that any offline-sync daemons uses IDLE though. isync / mbsync doesn't seem to either.
- cbcoutinho 7y ago
  I use a systemd timer to handle periodic calls to offlineimap, and that works really well compared to a corn-based work flow.
  - masklinn 7y ago
    systemd timers are a cron-based workflow. A cron-based workflow is when you periodically check for work to do rather than get notified that there's work to do.
    - cbcoutinho 7y ago
      Yes that's true that they periodically check for work to do, but cron is not smart enough to know whether a service is already running - a systemd-timer can base it's timer from the point when a service completes. I think cron just fires up a service unless you build in some logic to check if it's running
      - JdeBP 7y ago
        That's not really relevant. masklinn is contrasting periodic polling schemes like yours with using IDLE.
- naniwaduni 7y ago
  offlineimap does have IDLE support. It's known to exhibit hard-to-reproduce bugs, though.

BeetleB 7y ago

>A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. (I know mutt has an IMAP mode, and it looks like that's aerc's primary mode of operation, too, but I like to have a local copy of my entire mail archive.) What's wrong with fetchmail? Granted, it's not "as soon as it arrives", but you can run it every minute if you want.

def- 7y ago
You can use -d <interval> to run fetchmail in daemon mode and then use --idle so that the server can push messages to you immediately. (I also use unison to keep the mail directory synchronized between all my machines.)
Jaruzel 7y ago
These days, a lot of services with 2FA type emails or validation emails expect you to receive them within seconds. Also, how many times have you spoken to someone on the phone for them to say "I've just sent you the details.... can you see it yet?"
- codethief 7y ago
  > These days, a lot of services with 2FA type emails or validation emails expect you to receive them within seconds. Within seconds, really? I haven't encountered a single service like that. > Also, how many times have you spoken to someone on the phone for them to say "I've just sent you the details.... can you see it yet?" True but there's an easy solution: Fire up a terminal or even use a keyboard shortcut to run offlineimap manually within a split second.
  - pjc50 7y ago
    Well, you can't log in until you recieve the email. I've had a variant of this due to using a custom domain with a small email provider that was either slow or greylisting; the second-factor login email for GOG took longer than 15 minutes to arrive, by which time it had expired. I had to keep trying until it came through quickly enough.

coldtea 7y ago

>80-char lines are too short for desktop displays Nothing makes them "too short for desktop displays". Text is not supposed to fill all/most of the available display width: “Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line(counting both letters and spaces) is widely regarded as ideal.” -- The Elements of Typographic Style Applied to the Web

mrzool 7y ago
> Text is not supposed to fill all/most of the available display width That is pretty obvious, but every modern email client is able to deal with text wrapping itself. The only effect of the 80-char limit today is that of butchering your emails, especially on mobile. Since format=flowed is not supported enough, the only solution here is HTML.
- dmos62 7y ago
  Seconded, this kind of formatting shouldn't be hardcoded in the email. For me ideally, the presentation would be specified in the clients and it wouldn't be part of the message. Provided all emails are prose-like, which they are in my case.
tssva 7y ago
"The Elements of Typographic Style Applied to the Web" was originally released in 2005 and I'm afraid some of the advice may be stuck there. This advice being among that advice. In 2005 many displays were still 4:3 ratio and this advice more applicable. With modern 16:9 ratio screens 66 character line lengths can seem extremely short and require unnecessary vertical scrolling to view a message with such line length. I find it quite visually jarring to receive an email with a fixed width that wastes the horizontal space of the viewing window. Instead of being fixed width the text should be reflowed to properly fill the viewing window.
- sagichmal 7y ago
  The optimal width of a column of text is not a function of the container it is in, or the screen it is displayed on, but rather a constant based on the capacities of human vision. It's roughly empirically accepted that it's easier for us to read a block of text that flows from one line to the next after approximately 65-85 characters. Thus that extra space on the margins isn't wasted, it's serving an important purpose.

mrzool 7y ago

> Rendering plain text markdown into multipart/html emails. [...] 80-char lines are too short for desktop displays and too long for small phones (leading to awful linebreaks), which makes me the guy whose emails never look right. I completely agree! That's exactly the feature I requested, for exactly the same reasons, to the developers of Neomutt. I was pleasantly surprised when it turned out they were open to the idea. They got it implemented eventually. The discussion is here: https://github.com/neomutt/neomutt/issues/587 https://github.com/neomutt/neomutt/issues/587

pwg 7y ago

> 80-char lines are too short for desktop displays and too long for small phones What you want is format=flowed emails. Check the mutt manual (http://www.mutt.org/doc/manual.txt http://www.mutt.org/doc/manual.txt for format=flowed and this blog post (https://brianbuccola.com/line-breaks-in-mutt-and-vim/ https://brianbuccola.com/line-breaks-in-mutt-and-vim/). And for details on format=flowed, read here: https://joeclark.org/ffaq.html https://joeclark.org/ffaq.html

mrzool 7y ago
It would be great if it was so easy. Sadly it’s not, because format=flowed is ignored by many email clients. See also: https://github.com/neomutt/neomutt/issues/587 https://github.com/neomutt/neomutt/issues/587 Also this article: https://fastmail.blog/2016/12/17/format-flowed/ https://fastmail.blog/2016/12/17/format-flowed/ The only solution is HTML and multipart emails. Edit: added link to article
nextos 7y ago
I've given up on format=flowed because if you are not really careful to insert hard newlines, it can break inline attachments. In fact, hardcore users of plain text email like LKML discourage it for this reason. That said, it's nice to see a new text-oriented mail client. I remain skeptical about Unix interactive text-mode applications, though. Unlike classical Unix tools, more complex interactive applications do not compose well. They are little silos. I was a long term Mutt user, but I eventually moved my email into Emacs. That was because Emacs applications feel part of a consistent environment, a text-mode Lisp VM. They can easily talk to each other, and you can extend them beyond their designers ideas. On Mutt on the other hand, any non-trivial extension was just a pile of hacks. For example, multiple accounts. I encourage HN users to take a look at Notmuch, both as a MUA inside Emacs or elsewhere, it has a really nice architecture. It's kind of a side-effect free mail user agent.

wazoox 7y ago

> A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. fetchmail + procmail do just that. Use the Unix way :)

nulbyte 7y ago

> * A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. You can do this with fetchmail and procmail.[1] [1] http://www.ioncannon.net/system-administration/97/using-fetchmail-and-procmail-for-maildir-style-storage-from-a-pop3-account/ http://www.ioncannon.net/system-administration/97/using-fetc...

zeveb 7y ago

> A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. I've used both OfflineIMAP & mbsync for this; I'd recommend the latter these days. Works great. > Rendering plain text markdown into multipart/html emails. I have a feeling you could do something with emacs & one of its mail modes to do this, by slapping something into a hook … Ah, this guys looks to have come up with a way: https://ioctl.it/posts/2015-03-18-emacs-html-mail.html/ https://ioctl.it/posts/2015-03-18-emacs-html-mail.html/

masukomi 7y ago

Markdown -> HTML without killing the ability for text clients like the one I was using was a must have before I would switch to (neo)mutt. Here's how I managed to do it. text/plain (markdown) -> multipart/alternative with neomutt macro compose K "| pandoc -f markdown -o /tmp/neomutt-alternative.html<enter><attach-file>/tmp/neomutt-alternative.html<enter><tag-entry><previous-entry><tag-entry><group-alternatives>"

chme 7y ago

I am currently a bit unhappy with html rendering on the terminal as well, but for another reason: Links What I would wish for is some way to render the html link text as well as the address in the terminal, so that I can easily open those in a browser. I have looked into a way to convince w3m to do that, but haven't found one yet.

Fnoord 7y ago
Try Browsh, it is Firefox for the terminal.
megous 7y ago
The only workable solution (with mutt) so far is to have a program bound to a key to extract the links and allow you to select one of them and open it via xdg-open.

amiga_500 7y ago

offlineimap does this, write to Maildir then have mutt use this.