Aerc – An email client that runs in the terminal(aerc-mail.org)
aerc-mail.org
Aerc – An email client that runs in the terminal
https://aerc-mail.org/
271 comments
> 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 for format=flowed and this blog post (https://brianbuccola.com/line-breaks-in-mutt-and-vim/).
And for details on format=flowed, read here: https://joeclark.org/ffaq.html
What you want is format=flowed emails.
Check the mutt manual (http://www.mutt.org/doc/manual.txt for format=flowed and this blog post (https://brianbuccola.com/line-breaks-in-mutt-and-vim/).
And for details on format=flowed, read here: https://joeclark.org/ffaq.html
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.
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.
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
Also this article: https://fastmail.blog/2016/12/17/format-flowed/
The only solution is HTML and multipart emails.
Edit: added link to article
See also: https://github.com/neomutt/neomutt/issues/587
Also this article: https://fastmail.blog/2016/12/17/format-flowed/
The only solution is HTML and multipart emails.
Edit: added link to article
>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
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
> 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.
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.
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.
"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.
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.
I got typographic education, and the reason we limit line with on paper (think about the biggest newspaper you know), isn’t because the lack of space. I know newspapers that are bigger than any typical display you’d find at a work place.
Shorter lines are easier and faster to read and you don’t have to turn your head back and forth every line. This is what German Typographers would call a Bleiwüste, which means “lead desert” and translates to wall of text. And they call it that for a reason. Typographers use a wall of text when they want to disencourage users from reading it (legal text etc).
Column based layouts (like in newspapers) don’t work well with scolling pages, but limited line width certainly does. Scrolling doesn’t really cost the user much and on top of that smartphones limit the line width anyway, so users get a more consistent design.
Shorter lines are easier and faster to read and you don’t have to turn your head back and forth every line. This is what German Typographers would call a Bleiwüste, which means “lead desert” and translates to wall of text. And they call it that for a reason. Typographers use a wall of text when they want to disencourage users from reading it (legal text etc).
Column based layouts (like in newspapers) don’t work well with scolling pages, but limited line width certainly does. Scrolling doesn’t really cost the user much and on top of that smartphones limit the line width anyway, so users get a more consistent design.
I think you minimize the impact of scrolling. I fine scrolling to be extremely distracting and annoying when the material could have been presented without requiring scrolling.
On my computer I can resize windows and within some apps such as my email app the display view so that it meets what is optimal for me and not some generalized value. It is not unreasonable to expect the text presented to me to reflow to meet my preference.
On my computer I can resize windows and within some apps such as my email app the display view so that it meets what is optimal for me and not some generalized value. It is not unreasonable to expect the text presented to me to reflow to meet my preference.
>"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.
The advice given wasn't based on the technology of the era, but on the optimal line length for reading in general.
That's invariant to how more wide a screen one has (or to whether the "text" looks not wide enough compared to the screen), and based on how far the eyes should go to read something, and whether the reader loses their place (line they are in etc) by the time the roll back and forth at the end of a line to start the new one.
>Instead of being fixed width the text should be reflowed to properly fill the viewing window.
That's the worst possible situation, and not found to be good by any reading research (on paper or screen).
The advice given wasn't based on the technology of the era, but on the optimal line length for reading in general.
That's invariant to how more wide a screen one has (or to whether the "text" looks not wide enough compared to the screen), and based on how far the eyes should go to read something, and whether the reader loses their place (line they are in etc) by the time the roll back and forth at the end of a line to start the new one.
>Instead of being fixed width the text should be reflowed to properly fill the viewing window.
That's the worst possible situation, and not found to be good by any reading research (on paper or screen).
First of all given the issues with reproducibility within both hard sciences and especially soft sciences I will have to take any results from reading research with a grain of salt until I am able to actually read the specifics of any study. But even for purposes here if I say I accept the results than still the best it can produce regarding a fixed character length is a number which best meets the need of the population as a whole. Which means it might not be the optimal number for me. The great thing about my computer is that I can adjust windows and text view sizes to what I find optimal for myself. It is not unreasonable to expect text adjust to the setting I have chosen as optimal for myself.
Both the expectation that text will reflow and that 66 character line lengths are too short is not unique to me. A quick Google search returns a large number of hits regarding people looking for ways to have either the emails they send or receive be reflowed in their email app.
Both the expectation that text will reflow and that 66 character line lengths are too short is not unique to me. A quick Google search returns a large number of hits regarding people looking for ways to have either the emails they send or receive be reflowed in their email app.
"Text is not supposed to fill all/most of the available display width"
Eh... What else is it supposed to do in a terminal? Of course I want text to fill as much space as possible.
Eh... What else is it supposed to do in a terminal? Of course I want text to fill as much space as possible.
Maybe you do, but chances are that other people use terminals that are wider than they'd find comfortable for body text.
The ideal to me would be optional, backwards compatible re-flow like RFC 3676, but that doesn't seem to have caught on.
The ideal to me would be optional, backwards compatible re-flow like RFC 3676, but that doesn't seem to have caught on.
Strangely, HN seems a bit too wide even if you limit it to 75 characters. The following looks much better imho:
.comment { width: 50em; }
.comment { width: 50em; }
I like `50ch` myself, but it's still workable up to about 65ch. (Aside) look into the ch unit if you've not used it since it is width based vs em which is height based it is a great choice for something like line lengths.
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/
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/
> 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.
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.
Doesn’t claws have a reusable library for that sort of thing?
> 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 :)
fetchmail + procmail do just that. Use the Unix way :)
>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.
What's wrong with fetchmail? Granted, it's not "as soon as it arrives", but you can run it every minute if you want.
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.)
(I also use unison to keep the mail directory synchronized between all my machines.)
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?"
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?"
> 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.
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.
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.
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.
> 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
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
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.
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/
> 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.
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.
Trailing whitespace gets lost easily in editors. Mail clients not designed around HTML mail often track lines rather than paragraphs, and don't distinguish "hard wraps" and "soft wraps". The concept of "format=flowed" itself can get mangled if someone with a mail client that doesn't support it replies. And yes, people do send things like ASCII art or underlined text or code or other things where whitespace and wrapping matters.
> Trailing whitespace gets lost easily in editors.
As far as I'm aware, mail clients typically don't modify quoted text beyond prepending each line with a > character. Even if the trailing whitespace is lost, then you'll just have a conventional hard wrapped message (which is no different than just using a mail client that doesn't support format=flowed).
> The concept of "format=flowed" itself can get mangled if someone with a mail client that doesn't support it replies.
Not in my experience. If they remove the trailing whitespace, then it's essentially hard-wrapped again. If they don't, then it's still flowed.
> And yes, people do send things like ASCII art or underlined text or code or other things where whitespace and wrapping matters.
In that case, the flowed option isn't suitable. The RFC I referenced does support a fixed option for the format parameter which would address that issue. Also, Thunderbird did not attempt to append whitespace to previously quoted material if it didn't have it already.
In any case, the flowed format would work perfectly for this particular thread since no one is hard wrapping anything.
As far as I'm aware, mail clients typically don't modify quoted text beyond prepending each line with a > character. Even if the trailing whitespace is lost, then you'll just have a conventional hard wrapped message (which is no different than just using a mail client that doesn't support format=flowed).
> The concept of "format=flowed" itself can get mangled if someone with a mail client that doesn't support it replies.
Not in my experience. If they remove the trailing whitespace, then it's essentially hard-wrapped again. If they don't, then it's still flowed.
> And yes, people do send things like ASCII art or underlined text or code or other things where whitespace and wrapping matters.
In that case, the flowed option isn't suitable. The RFC I referenced does support a fixed option for the format parameter which would address that issue. Also, Thunderbird did not attempt to append whitespace to previously quoted material if it didn't have it already.
In any case, the flowed format would work perfectly for this particular thread since no one is hard wrapping anything.
Thus the nickname: format=flawed
> 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
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
> * 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-fetc...
You can do this with fetchmail and procmail.[1]
[1] http://www.ioncannon.net/system-administration/97/using-fetc...
> 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/
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/
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>"
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>"
Checkout offlineimap.
Mutt can then use the synched directory from offlineimap.
Mutt can then use the synched directory from offlineimap.
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.
I don't know that any offline-sync daemons uses IDLE though. isync / mbsync doesn't seem to either.
I wrote my own IMAP IDLE watcher (https://github.com/rakoo/). It only watches for IDLE events, all the actual mail retrieval is done by offlineimap. It's simplistic but it does (did) the job.
offlineimap does have IDLE support. It's known to exhibit hard-to-reproduce bugs, though.
> IDLE support is incomplete and experimental. Bugs may be encountered.
That's not "have IDLE support".
That's not "have IDLE support".
I use a systemd timer to handle periodic calls to offlineimap, and that works really well compared to a corn-based work flow.
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.
A cron-based workflow is when you periodically check for work to do rather than get notified that there's work to do.
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
That's not really relevant. masklinn is contrasting periodic polling schemes like yours with using IDLE.
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.
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.
offlineimap does this, write to Maildir then have mutt use this.
I saw the title [was: "World's Best Email Client"] and thought, "yeah, sure".
But WOW. It's the e-mail of my dreams. Take my money, damn you!
EDIT: I may have been seduced by the clicky keyboard noises in the video. But no! Is good!
EDIT2: I forgive you for Wayland.
But WOW. It's the e-mail of my dreams. Take my money, damn you!
EDIT: I may have been seduced by the clicky keyboard noises in the video. But no! Is good!
EDIT2: I forgive you for Wayland.
Off-topic, but damn, Drew, how do you manage to be so productive? Sway alone is an impressive beast (and the only thing that got me off my awesomewm addiction). Now you're throwing in an impressive mutt alternative? Thanks for all the hard work!
[–]drewdevault[S] 26 points 17 hours ago
I work on free software full-time now thanks to the support of the many people who donate to my work :)
https://drewdevault.com/2019/01/15/Im-doing-FOSS-full-time.h...
Lots of people help with these projects, too. aerc 0.1.0 includes contributions from a total of 16 authors.
From: https://old.reddit.com/r/linux/comments/bwao4d/aerc_an_email...
I work on free software full-time now thanks to the support of the many people who donate to my work :)
https://drewdevault.com/2019/01/15/Im-doing-FOSS-full-time.h...
Lots of people help with these projects, too. aerc 0.1.0 includes contributions from a total of 16 authors.
From: https://old.reddit.com/r/linux/comments/bwao4d/aerc_an_email...
I dunno what it is about the screencast, but it takes _forever_ to load. Any chance you could upload to Youtube or something so that I can actually watch the thing?
EDIT: I'm getting about 20kb/s download from sr.ht where the video is hosted. Definitely not an issue with my connection, as I can download other files right now at 2Mb/s.
EDIT: I'm getting about 20kb/s download from sr.ht where the video is hosted. Definitely not an issue with my connection, as I can download other files right now at 2Mb/s.
Agree. Can he throw it on Streamable or something?
EDIT: Here it is: https://streamable.com/3ysv9
EDIT: Here it is: https://streamable.com/3ysv9
Native player in Chrome doesn't seem to download videos in big enough chunks or doesn't buffer well enough for smooth playback in some cases. I've seen it several times myself.
[deleted]
Neat! I used to be a kernel maintainer, and had a similar setup going inside emacs with gnus, and dvc-git commands bound to keys to apply patches. Here's an old blog post about some of it:
https://blog.printf.net/articles/2010/10/04/git-patches-in-g...
Gnus was too slow, but worse, emacs is single-threaded, so e.g. polling for new mail in the background blocked the rest of the editor while it happened. I never understood why it was impossible to have any kind of multithreading in emacs.
https://blog.printf.net/articles/2010/10/04/git-patches-in-g...
Gnus was too slow, but worse, emacs is single-threaded, so e.g. polling for new mail in the background blocked the rest of the editor while it happened. I never understood why it was impossible to have any kind of multithreading in emacs.
Hey, would you mind writing up some details about your email setup for kernel work to [email protected]? I'd like to understand more email-driven workflows, especially from kernel maintainers, to guide aerc's design.
Hm! I can't think of much to add, except.. the next thing I would've worked on might've been to integrate a client for https://patchwork.kernel.org/ to keep it in sync and mark patches there as handled.
Thanks! I wonder if you've seen my work with mailing lists on sourcehut, by the way?
https://sourcehut.org
I'm working on a replacement for patchwork. Here's an example of a thread which was rendered with my tool, which is just generated from organic mail threads without extra human intervention:
https://lists.sr.ht/~philmd/qemu/patches/5556
If you have more feedback or thoughts around this, I'd love to hear it too :)
https://sourcehut.org
I'm working on a replacement for patchwork. Here's an example of a thread which was rendered with my tool, which is just generated from organic mail threads without extra human intervention:
https://lists.sr.ht/~philmd/qemu/patches/5556
If you have more feedback or thoughts around this, I'd love to hear it too :)
A Patchwork client (well, a tool that does some of the more useful patchwork status updating, it's not a full client as such) for notmuch, which has a number of kernel dev users: https://github.com/stewart-ibm/pwnm-sync
> I never understood why it was impossible to have any kind of multithreading in emacs.
There are various ways to do multithreading in emacs now, but the answer to your question is usually “there’s a lot of existing elisp that isn’t thread-safe”, and that’s still kind of a problem.
There are various ways to do multithreading in emacs now, but the answer to your question is usually “there’s a lot of existing elisp that isn’t thread-safe”, and that’s still kind of a problem.
I’m still a novice functional programmer so this may be a dumb comment but I thought a lisp would be more thread safe due to immutable data structures.
Not all fp languages are purely functional, and certainly not all lisps. In fact, the only lisp that I'm aware of that focuses on immutability is clojure. Granted, many lisp programmers may decide to keep their functions pure, but it's rarely enforced.
Lisp is not a functional language. Or, not an obligate-functional language. I.e. you can do functional if you like, but where it becomes a PITA, you can just assign. Because of that, many optimizations possible in obligate-functional languages are not safe. Because of that, you sometimes need to do your own such optimizations, non-functional-wise.
But it is still easier to get fast code than in an obligate-functional language, because in the latter it is indefinitely hard to predict where such optimizations, where permitted, would actually happen; and in some cases they are not allowed anyway. The tradeoff is that in Lisp (as in other imperative languages) you have to do them yourself where you want them. But you can choose to do them only in hot paths, a tiny fraction of your code.
But it is still easier to get fast code than in an obligate-functional language, because in the latter it is indefinitely hard to predict where such optimizations, where permitted, would actually happen; and in some cases they are not allowed anyway. The tradeoff is that in Lisp (as in other imperative languages) you have to do them yourself where you want them. But you can choose to do them only in hot paths, a tiny fraction of your code.
I "solved" this by having a separate emacs instance where I'd do mail and usenet.
So far, Gnus is still the best mail client in a terminal (that you can have the same instance in a tty and a X11 environment is just a bonus).
Aerc looks interesting but then there's the ugly truth that I do much less mail than I used to do 10 years ago. So I probably won't switch even if it's looking really sexy.
So far, Gnus is still the best mail client in a terminal (that you can have the same instance in a tty and a X11 environment is just a bonus).
Aerc looks interesting but then there's the ugly truth that I do much less mail than I used to do 10 years ago. So I probably won't switch even if it's looking really sexy.
For those of you already using emacs, this mirrors my workflow in mu4e.
Here are some screenshots[0], and here is a guide on how to set up mu4e[1].
[0] https://www.djcbsoftware.nl/code/mu/mu4e.html
[1] http://cachestocaches.com/2017/3/complete-guide-email-emacs-...
Here are some screenshots[0], and here is a guide on how to set up mu4e[1].
[0] https://www.djcbsoftware.nl/code/mu/mu4e.html
[1] http://cachestocaches.com/2017/3/complete-guide-email-emacs-...
My main concern with mu4e is that I have to fetch all the emails on my local machine. That's terrible, hope one day there will be a mu4e-like client for emacs with a thunderbird-like workflow, aka fetch in a lazy manner, before reading.
I am the opposite of you, I prefer all my email to be avaialble offline to me. I use offlineimap to mirror my remote IMAP folders, and usually read them with mutt, but occasinaly read them in GUI emacs where the terminal does not support RTL, such as Arabic emails.
>I am the opposite of you, I prefer all my email to be avaialble offline to me.
Even spam or mails you want to delete before reading? There are dozens of mails I want to delete or put to the archive folder before reading, thus this feature is annoying me. And when I want to backup mail, I use offlineimap explicitly.
Besides, I use mu4e of 3 separate machines, and on each I have to keep a local copy of all my mails, even mails I've read already.
Even spam or mails you want to delete before reading? There are dozens of mails I want to delete or put to the archive folder before reading, thus this feature is annoying me. And when I want to backup mail, I use offlineimap explicitly.
Besides, I use mu4e of 3 separate machines, and on each I have to keep a local copy of all my mails, even mails I've read already.
I selectively choose which IMAP dirs to sync. ``Spam`` isn't one of them. I do however sync my ``Archive`` or ``ALLAMIL`` dir as I often need to quickly grep (notmuch) for messages wihout having network connectivity.
I'm quite interested in both terminal emulators and internationalization. Curious if you've tried out mlterm and what issues you might have run into regarding rtl. Actually, I'd be interested to hear any of your stories regarding rtl in cli tools.
sorry just seen this now. I have not tried mlterm, and have not actually heard of it before! I just looked it up and I will defintely check it out.
I love gnome, but on occasions I switch to KDE, where Konsole terminal has better Arabic support.
I love gnome, but on occasions I switch to KDE, where Konsole terminal has better Arabic support.
Is Sir_Cmpwn a person or a committee? How can one person produce so much decent software?
I was thinking exactly this. It's unbelievable the amount of amazing things Drew has been putting out there recently.
I suspect it's because he's so successful at spawning developer communities around the software he writes. Just look at sway: between 1.0 and 1.1 he was nowhere near the largest contributor. I'd guess that means a lot of time to work on other projects.
Drew works full-time on free software and is extremely good at it.
https://news.ycombinator.com/item?id=18920604
https://news.ycombinator.com/item?id=18920604
@Sir_Cmpwn do you have some insights to share on this? What are the conditions that make you most productive, and what conditions make you the least productive?
I get a lot of help. Fostering a healthy and happy community of contributors in each of my projects is extremely important to me. I'm also able to be more productive myself thanks to the support of hundreds of people who donate to my work or buy a sourcehut subscription, which allows me to work on free software full time.
Any advice or insights on creating and fostering that community for your projects?
Perfect! Thank you :)
How easy is it to tell it what IMAP folders to use for sent mail, deleted mail, and drafts?
A while back, I engaged in epic combat against Apple Mail on my Mac, Apple's iOS mail app on my iPhone, Outlook on my Mac, Outlook on my gaming PC, Outlook on my Surface Pro 4, and Thunderbird on my Mac to banish the blight of, e.g., Sent, Sent Mail, and Sent Messages, and similar for drafts and deleted.
It was an epic struggle, but I finally got them to all agree on Sent, Trash, Drafts (and Junk for spam). I'm not going near any other email client now without being sure I can tell it to use those before I let it have access to my IMAP.
A while back, I engaged in epic combat against Apple Mail on my Mac, Apple's iOS mail app on my iPhone, Outlook on my Mac, Outlook on my gaming PC, Outlook on my Surface Pro 4, and Thunderbird on my Mac to banish the blight of, e.g., Sent, Sent Mail, and Sent Messages, and similar for drafts and deleted.
It was an epic struggle, but I finally got them to all agree on Sent, Trash, Drafts (and Junk for spam). I'm not going near any other email client now without being sure I can tell it to use those before I let it have access to my IMAP.
Easy, you can change what folder it treats as sent. It doesn't have a trash bin (and it won't) or draft support (and it will) yet.
Out of curiosity, why won’t there be a Trash bin? What about an Archive folder?
Well, you can get both by just adjusting your keybindings a bit. For example, add this to binds.conf:
[messages]
D = :mv Trash<Enter>
A = :mv Archive<Enter>Perfect! That’s great to know that there are adjustable key bindings (although, I don’t know why I didn’t expect that!)
Thanks for all the hard work. Every year or so I try to switch my email workflow over to Mutt. I think I know what I’m trying this year!
Thanks for all the hard work. Every year or so I try to switch my email workflow over to Mutt. I think I know what I’m trying this year!
Trash bin (for messages, or files) is a poor man's replacement for making backup copies.
I think that's an oversimplification.. let's say I have daily backups. Let's also say I'm opening my email client in the morning and receive 20 mails, but because I haven't had any coffee yet I accidentally delete the wrong one, which I realize 15 seconds later. Now that mail is gone and I have no way to retrieve it..
(No, paying more attention is not a solution. People inevitably make these kinds of mistakes)
(No, paying more attention is not a solution. People inevitably make these kinds of mistakes)
Yes, I admit, backups alone is too narrow a solution. Still, it's a terminal program, apparently not targeted towards general mouse-and-click user. Here, you probably can assign a key(combination) to 'mv Trash' instead of deletion if you like it, or just have no keybinding at all, forcing yourself to type ":delete" (or whatever the command to delete is in Aerc).
I think each client decides, or can make its own decision.
This problem comes up a lot if you have a client that wasn't set with English as the default language.
This problem comes up a lot if you have a client that wasn't set with English as the default language.
Love the idea, and I really will give this a go as a daily driver.
Just a small feedback: I had trouble with one of the requirements -> scdoc, didn't know what exactly that is (Googling didn't help), so might be worth to provide a direct link in the README.md to https://git.sr.ht/~sircmpwn/scdoc/
Just a small feedback: I had trouble with one of the requirements -> scdoc, didn't know what exactly that is (Googling didn't help), so might be worth to provide a direct link in the README.md to https://git.sr.ht/~sircmpwn/scdoc/
scdoc is probably available in your Linux distro's package manager, and aerc is designed to be packager-friendly - so eventually the idea is that most users will apt install aerc, rather than build it themselves.
Yeah, the problem is I am on OSX, and I actually had to compile scdoc myself without the -static flag (missing libraries).
Also, I had to run it as:
Also, I had to run it as:
TERM=xterm-256color aerc
panic: terminal entry not foundTo get this to install on osx
1. git clone https://git.sr.ht/~sircmpwn/scdoc
2. Edit Makefile and remove -static flag from ldflags
3. make install
4. git clone https://git.sr.ht/~sircmpwn/aerc
5. make install
You will need Go 1.12
1. git clone https://git.sr.ht/~sircmpwn/scdoc
2. Edit Makefile and remove -static flag from ldflags
3. make install
4. git clone https://git.sr.ht/~sircmpwn/aerc
5. make install
You will need Go 1.12
This issue comes from tcell, which has a baked-in terminfo database. I'm also not sure about the state of the terminfo database in general on OSX... in any case, I plan on improving terminfo support in tcell at some point.
It's probably because i use xterm-kitty.
Awesome work on aerc, looking forward for continued development.
Awesome work on aerc, looking forward for continued development.
Can confirm, am running Kitty too and ran into exact same error messages, exporting different TERM environment variable did fix this though!
I'm on Ubuntu 18.04 at work and I don't have scdoc available.
(base) eximius@eximius-nuc:~/go/src/aerc-0.1.0$ apt-cache search scdoc
(base) eximius@eximius-nuc:~/go/src/aerc-0.1.0$
package git.sr.ht/~sircmpwn/aerc/commands: unrecognized import path "git.sr.ht/~sircmpwn/aerc/commands" (parse https://git.sr.ht/~sircmpwn/aerc/commands?go-get=1: no go-import meta tags ())
https://repology.org/project/scdoc/badges
You need go 1.12.
You need go 1.12.
Thank you, I had the same problem. Apt couldn't find it in my Ubuntu 18.04.2 LTS install, and when I googled it I'm pretty sure "South Carolina Department of Corrections" wasn't what I was looking for. ;) So, thank you for the link.
I really, really like that the editor is embedded within the mail client. The need to shell out to vim or whatever is what always kept me from using Mutt, despite loving its UI.
aerc isn't quite as colorful or well-laid-out as Mutt but this is very promising.
This reminds me a lot of my all-time favorite mail editor, which I miss dearly: GoldED [0] [1]
[0] https://en.wikipedia.org/wiki/GoldED
[1] https://blog.onlime.ru/wp-content/uploads/2018/12/CwkTcNSWQA... (Russian screenshot but you get the idea)
aerc isn't quite as colorful or well-laid-out as Mutt but this is very promising.
This reminds me a lot of my all-time favorite mail editor, which I miss dearly: GoldED [0] [1]
[0] https://en.wikipedia.org/wiki/GoldED
[1] https://blog.onlime.ru/wp-content/uploads/2018/12/CwkTcNSWQA... (Russian screenshot but you get the idea)
I use pine (alpine) as my primary (and only) mailtool - and have since 1993.
Further, all rsync.net employees use pine for all rsync.net email. One interesting side-effect of this is that employee to employee emails are simply a local copy operation - they never traverse a network.
If you're looking into a mailtool that can run in the terminal (like this, or like mutt or (al)pine) I encourage you to consider running that mailtool on the actual machine with your mailspool. It allows your email to show up in your INBOX immediately and, as described above, allows for email interactions that don't leave the server ...
Further, all rsync.net employees use pine for all rsync.net email. One interesting side-effect of this is that employee to employee emails are simply a local copy operation - they never traverse a network.
If you're looking into a mailtool that can run in the terminal (like this, or like mutt or (al)pine) I encourage you to consider running that mailtool on the actual machine with your mailspool. It allows your email to show up in your INBOX immediately and, as described above, allows for email interactions that don't leave the server ...
It’s still around: https://repo.or.cz/alpine.git
I've been using it (Pine, the Alpine) as my primary mail client since 1998.
Months after i started using it, someone suggested i try mutt. I'm definitely going to, but i haven't got round to it yet.
Months after i started using it, someone suggested i try mutt. I'm definitely going to, but i haven't got round to it yet.
Oh, I used this back in the mid-90s and it was SO good!
If you liked Pine you will probably like Alpine and Pico's successor, Nano.
What is the problem with Mutt though? Does Aerc have color or themeing support? Does it have a seperate daemon to talk the email protocols such as IMAP4?
What is the problem with Mutt though? Does Aerc have color or themeing support? Does it have a seperate daemon to talk the email protocols such as IMAP4?
I am a Nano user! Very happy. Vim users be hatin~
mutt is single threaded, for a start.
My least favorite email begins with a +Russell at the top, meaning that there's been a long email thread that I haven't been a part of, and now I've been pulled in. The text below that is your standard mess of email text: 1) It's in reverse chronological order starting at the bottom. 2) Each message has 4 or 5 lines of "to", "from", "cc", "subject" and "date" in between. 3) Previous messages might or might not be repeated by other email clients 4) All with varying levels of indenting.
This has to be a common problem. Are there any libraries, projects, email clients or scripts to help parse it all into something readable? I've looked and haven't found zip. I know Slack is the new hotness, but for the rest of us stuck in email, this is a daily hell. The progress of email clients basically stopped in the mid-2000s.
I swear, the first email client that actually solves this problem will be the next billion dollar business.
This has to be a common problem. Are there any libraries, projects, email clients or scripts to help parse it all into something readable? I've looked and haven't found zip. I know Slack is the new hotness, but for the rest of us stuck in email, this is a daily hell. The progress of email clients basically stopped in the mid-2000s.
I swear, the first email client that actually solves this problem will be the next billion dollar business.
The solution is to have the thread forwarded as message/rfc822 attachments instead of full quote madness.
This is definitely already a solved problem - for open or homogeneous platforms. This is why it's still an issue for everyone else... Microsoft's general attitude is, "everyone should use Outlook", Apple wants you to use Mail, Google wants everyone on Gmail, etc. I'm sure this is rarely an issue inside those companies - threading "just works" since coworkers all use the same clients. So not only do they have zero financial reason to support interop or openness, they probably don't even know its an issue.
How's the UTF-8 e-mail address support? As most clients suck so bad at that it would be awesome to have an alternative.
How's the GPG and S/MIME support? We'd really need an e-mail client that has first class support of both. Current solutions I've tried are cumbersome at best.
Having those two it'd actually be the best e-mail client for me.
How's the GPG and S/MIME support? We'd really need an e-mail client that has first class support of both. Current solutions I've tried are cumbersome at best.
Having those two it'd actually be the best e-mail client for me.
UTF-8 support is excellent.
First-class PGP support is planned and a blocker for 1.0, but not there yet. Here's a mockup to tease you:
https://cmpwn.com/system/media_attachments/files/000/351/218...
https://cmpwn.com/system/media_attachments/files/000/351/219...
First-class PGP support is planned and a blocker for 1.0, but not there yet. Here's a mockup to tease you:
https://cmpwn.com/system/media_attachments/files/000/351/218...
https://cmpwn.com/system/media_attachments/files/000/351/219...
I was about to ask about PGP support too so thanks for the screenshots, they look great!
Is PGP key discovery based on email planned/welcome? I'm talking about Web Key Directory introduced by GnuPG [0], being standardized by IETF [1] and already used by kernel.org [2], gentoo.org and others. GUI e-mail clients such as Enigmail or Mailpile support it but there is not CLI client with WKD.
[0]: https://wiki.gnupg.org/WKD
[1]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
[2]: https://www.kernel.org/category/signatures.html#using-the-we...
Is PGP key discovery based on email planned/welcome? I'm talking about Web Key Directory introduced by GnuPG [0], being standardized by IETF [1] and already used by kernel.org [2], gentoo.org and others. GUI e-mail clients such as Enigmail or Mailpile support it but there is not CLI client with WKD.
[0]: https://wiki.gnupg.org/WKD
[1]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
[2]: https://www.kernel.org/category/signatures.html#using-the-we...
Yes, I'd love to have WKD support.
> UTF-8 e-mail address support?
hard pass on this as it encourages dark patterns.
hard pass on this as it encourages dark patterns.
You mean like speaking any other language besides english?
I think he is thinking about that some letters look identical but are encoded differently. So someone will not be able to look at an email address and say: oh it’s from such and such.
Trusting one's eyes is doomed to failure anyway. That's what PGP is for.
That's a side-effect of UTF-8, yes, but my primary concern was indeed non-English e-mail addresses, people should have the right to use their own names. You have GPG for identity validation though.
good luck getting your mom to implement that.
It's not like your mom without UTF-8 and without GPG is protected against phishing either. UTF-8 lookalikes are only a teeny-tiny fraction of any phishing.
It's stupid anyways to rely on never having UTF-8 because most clients do it to the extent of making lookalikes possible, but not so that it's usable for internationalized e-mails. If anything, e-mail clients should have built-in warning against such attacks as well as you using proper methods of determining who you're e-mailing.
It's stupid anyways to rely on never having UTF-8 because most clients do it to the extent of making lookalikes possible, but not so that it's usable for internationalized e-mails. If anything, e-mail clients should have built-in warning against such attacks as well as you using proper methods of determining who you're e-mailing.
my mom is using a linux CLI mail client?
I used mutt+offlineimap for a few years, with a corporate account on an MSExchange Server and the two biggest issues I had (which I hope Aerc addresses) were:
* no good way to search/auto-complete addresses (I used vdirsyncer which got me the address book locally but there was no easy way to fill-in addresses when typing an email).
* no way to accept calendar requests - I would pull them up on my phone to accept or reject.
Otherwise, everything worked quite well, but those issues annoying enough that I eventually switched back to a Windows machine with Outlook. The Email+Calendar+Addressbook integration may violate the Linux philosophy of doing one thing well, but for today's typical office workflow it is frustrating not to have a platform with all three integrated.
* no good way to search/auto-complete addresses (I used vdirsyncer which got me the address book locally but there was no easy way to fill-in addresses when typing an email).
* no way to accept calendar requests - I would pull them up on my phone to accept or reject.
Otherwise, everything worked quite well, but those issues annoying enough that I eventually switched back to a Windows machine with Outlook. The Email+Calendar+Addressbook integration may violate the Linux philosophy of doing one thing well, but for today's typical office workflow it is frustrating not to have a platform with all three integrated.
You might be interested in dav mail.
http://davmail.sourceforge.net/
I have it setup so I can use thunderbird for all my exchange interaction (except group management).
http://davmail.sourceforge.net/
I have it setup so I can use thunderbird for all my exchange interaction (except group management).
Thanks - I was actually using Davmail but at the time it did not have the address book and calendar integration, and I had not checked up on it ina few years. Looks like it has gotten more features since then. I may have to give mutt another try...:)
What about full text search? This feature has brought me to from mutt to sup to alot: https://alot.readthedocs.io/en/latest/
notmuch support is planned! It shouldn't be too hard, if an interested user were to take ownership over the feature it could probably ship in 0.2.0. Want to help?
Curious if you've looked at nmh and mu (maildir utils)? The last time I looked, it wasn't obvious that notmuch was the better option.
And also if you've looked at jmap? It's my distinct impression that the jmap effort isn't a case of nih, but rather stems from a real need of avoiding imap limitations (in idle, various levels of extension support).
One of my project ideas, for a long time, has been to figure out if dbmail might be tricked into being a decent jmap server via a graphql(like) proxy on top of postgres...
And also if you've looked at jmap? It's my distinct impression that the jmap effort isn't a case of nih, but rather stems from a real need of avoiding imap limitations (in idle, various levels of extension support).
One of my project ideas, for a long time, has been to figure out if dbmail might be tricked into being a decent jmap server via a graphql(like) proxy on top of postgres...
Since the client is written in Go, I believe this could be easily done with https://blevesearch.com
Eh, I would rather use notmuch than develop my own index from scratch. Keep it email, yo.
I'd leave Thunderbird in a heartbeat if I could find a contact/calendar syncing terminal client as well. Any recommendations?
I use Khard for contacts and khal for calendar.
Neither handle syncing, so I use vdirsyncer for that (you can use anything you like or just go local only).
https://github.com/scheibler/khard
https://github.com/pimutils/khal
https://github.com/pimutils/vdirsyncer
Neither handle syncing, so I use vdirsyncer for that (you can use anything you like or just go local only).
https://github.com/scheibler/khard
https://github.com/pimutils/khal
https://github.com/pimutils/vdirsyncer
I currently use Thunderbird for mail, and MineTime for calendar. I found the Thunderbird calendar integrations (5 calendars) way too flaky.
Would be good to have a calendar client in terminal.
MineTime looks cool, but I got a wrong feeling about the looks and yeah, scrolling down and I saw it: "MineTime is a calendar built on Electron". Nah, I prefer to have just one browser open (and not Chrome/Chromium).
MineTime looks cool, but I got a wrong feeling about the looks and yeah, scrolling down and I saw it: "MineTime is a calendar built on Electron". Nah, I prefer to have just one browser open (and not Chrome/Chromium).
Have a look at vdirsyncer, khard, and khal. This in combination with mbsyc is my CLI PIM sync :)
Nice, looking forward to trying it out. Other similar projects worth mentioning:
https://github.com/leahneukirchen/mblaze - As the author says, "Unix utilities to deal with maildir".
https://github.com/aligrudi/neatmail - A noninteractive client with ex-like commands
http://plan9.stanleylieber.com/mother/ - for Plan9 people.
https://github.com/leahneukirchen/mblaze - As the author says, "Unix utilities to deal with maildir".
https://github.com/aligrudi/neatmail - A noninteractive client with ex-like commands
http://plan9.stanleylieber.com/mother/ - for Plan9 people.
Thank you Sir_Cmpwn, awesome that someone is picking up where mutt left off.
My attempt was https://lumail.org/ a console-based mail-client inspired by mutt, but with 100% lua scripting.
Looks interesting!
Based on a quick stroll through the source code, I don't see any search integration. Is that correct?
I guess I could just shell out to notmuch? But I do find virtual folders for searches really convenient. Currently using neomutt with notmuch support, over a Maildir (which in turn is separately synced via IMAP using mbsync).
Not having all the context vanish ala mutt would sure be nice.
Based on a quick stroll through the source code, I don't see any search integration. Is that correct?
I guess I could just shell out to notmuch? But I do find virtual folders for searches really convenient. Currently using neomutt with notmuch support, over a Maildir (which in turn is separately synced via IMAP using mbsync).
Not having all the context vanish ala mutt would sure be nice.
There's a ticket planned for adding a notmuch backend straight up:
https://todo.sr.ht/~sircmpwn/aerc2/105
No indirection through mbsync & maildir. This shouldn't be terribly hard - if you're interested in working on this feature, swing by the IRC channel to get a rundown of the technical details.
There's also a ticket for search in general:
https://todo.sr.ht/~sircmpwn/aerc2/93
Which will probably be implemented for IMAP by 0.2.0.
https://todo.sr.ht/~sircmpwn/aerc2/105
No indirection through mbsync & maildir. This shouldn't be terribly hard - if you're interested in working on this feature, swing by the IRC channel to get a rundown of the technical details.
There's also a ticket for search in general:
https://todo.sr.ht/~sircmpwn/aerc2/93
Which will probably be implemented for IMAP by 0.2.0.
Thanks for the references!
I personally work offline for a fair bit (personally more productive that way, and I'm also traveling plenty for work). So I kinda like the mbsync & maildir indirection (although I do hate the lack of NOTIFY, and some other imap inefficiencies around not supporting QRESYNC etc).
I personally work offline for a fair bit (personally more productive that way, and I'm also traveling plenty for work). So I kinda like the mbsync & maildir indirection (although I do hate the lack of NOTIFY, and some other imap inefficiencies around not supporting QRESYNC etc).
i am looking forward to this. i am currently using supmua, the ancestor of notmuch, and i haven't been able to switch to any other notmuch based terminal client because their interfaces all felt inferior to sup. aerc is the first client i see that does the interface with multiple switchable screens right from the start. notmuch integration with the ability to keep virtual folders based on tags and on searches is the only thing keeping me from trying out aerc right now.
i'll be keeping an eye on it.
i'll be keeping an eye on it.
You should have a look at astroid (https://github.com/astroidmail/astroid). It is written by one of the ex-maintainers of sup but uses notmuch, so the workflows are mostly similar. It's not in a terminal though.
yeah, i am aware. if it wasn't for the terminal i would have tried it. but for my workflow, email in a terminal is a must.
Very cool!
How does this compare to sup / mutt / alpine / astroid ?
How does this compare to sup / mutt / alpine / astroid ?
I wonder how good it is with wide width characters (in CJK languages). Handling them in a terminal is rather tricky, and I haven't seen anything that's good except ones that are developed by the actual users of the language.
aerc dev here. I am a fluent speaker of Japanese and frequently work with CJK characters in the client.
I also think it is really only your terminal and fonts that have a say at how wide characters are handled (as well as Xresources if you run GNU/Linux). If you are on Linux a modern terminal emulator with great capabilities is kovidgoyal/kitty at Github.
Any idea how to fix this error?:
panic: Attempted to draw outside of context
goroutine 1 [running]:
git.sr.ht/~sircmpwn/aerc/lib/ui.(*Context).Printf(0xc0002fa450, 0x2, 0x1, 0x0, 0x84de7f, 0x4, 0xc0000d3c98, 0x1, 0x1, 0x50)
...
Try using a bigger terminal emulator. There's a ticket to deal with too-small terminals more elegantly but it hasn't been done yet.
What I miss is a low-resource email client with a GUI, something I (in principle) can run on a 20 year old computer.
Have you ever tried Claws[1]? I haven't used it for a while but when I did I was able to use it on quite older hardware running trimmed down versions of various Linux and BSD boxes.
Besides being light weight it's got some good features for an older client, it's GPL and can use plug-ins for extra functionality.
Nothing to do with he project, just a previously happy user.
[1] https://www.claws-mail.org/
Besides being light weight it's got some good features for an older client, it's GPL and can use plug-ins for extra functionality.
Nothing to do with he project, just a previously happy user.
[1] https://www.claws-mail.org/
Try claws or sylpheed (from which claws is derived), these work just fine on older hardware. Startup time (with cold cache) on my 14yo T42p is under a second, RSS is 48MB with 4 active multi-gigabyte IMAP accounts. There is a bunch of extensions to add PGP integration etc. On Debian the package is called 'claws-mail', this name might be different elsewhere.
I'm still using the last version (12.16) of the original Opera browser for its integrated email client. It has everything you may need (POP3, IMAP, HTML editor, threaded view, labels, multiple accounts, etc., etc.), it works wonderfully on Linux, and on old, low memory machines too.
Great work! I'm looking forward to using it full time. A couple of quick comments.
1. It doesn't seem to work with when $TERM is set to some non-default setting. (panic: terminal entry not found) 2. When term is forced to xterm-256-color, aerc crashes when the window is resized.
1. It doesn't seem to work with when $TERM is set to some non-default setting. (panic: terminal entry not found) 2. When term is forced to xterm-256-color, aerc crashes when the window is resized.
It can't do maildir. I tried mdir:/// maildir:/// file:/// and /.
grep -R maildir of the code returns nothing.
So I guess, using it on local mail is a no go. Sad. I tried it only because this was advertised, only to be disappointed.
It's better to not advertise features you don't have. Or at least state what features you have instead of mixing what you have and have not into a feature list at random.
It's also far cry from the configurability of the mutt/neomutt. But that can change. It would certainly be nice to have a properly scriptable terminal based MUA, as neomutt, while nice, and flexible, is kind of hard to configure.
grep -R maildir of the code returns nothing.
So I guess, using it on local mail is a no go. Sad. I tried it only because this was advertised, only to be disappointed.
It's better to not advertise features you don't have. Or at least state what features you have instead of mixing what you have and have not into a feature list at random.
It's also far cry from the configurability of the mutt/neomutt. But that can change. It would certainly be nice to have a properly scriptable terminal based MUA, as neomutt, while nice, and flexible, is kind of hard to configure.
There's a big red disclaimer on this page that says the feature list is a bit wishful, and the latest version is only 0.1.0. The docs (man pages, start with man aerc) only document implemented features, you may want to start there.
Here's the ticket for maildir support:
https://todo.sr.ht/~sircmpwn/aerc2/16
Several people have expressed interest in working on this, I expect we'll see it for 0.2.0.
As far as configurability is concerned, yeah, the plan is to continue making it more customizable and configurable. Stuff like filters already afford you a lot of options today. At some point I might also be interested in adding a fifo you can use to feed commands into it from a script, too, for turing-complete customization.
Here's the ticket for maildir support:
https://todo.sr.ht/~sircmpwn/aerc2/16
Several people have expressed interest in working on this, I expect we'll see it for 0.2.0.
As far as configurability is concerned, yeah, the plan is to continue making it more customizable and configurable. Stuff like filters already afford you a lot of options today. At some point I might also be interested in adding a fifo you can use to feed commands into it from a script, too, for turing-complete customization.
Yeah, I read it, assumming that easier features would be implemented first.
I still think it's better to split the list into what is completed and roadmap. It would help me track the progress.
Anyway, good luck. I'll keep my eye on the project, because it certainly seems interesting.
I still think it's better to split the list into what is completed and roadmap. It would help me track the progress.
Anyway, good luck. I'll keep my eye on the project, because it certainly seems interesting.
I don't believe on implementing the easy features first. If you implement the hard features first, its smooth sailing for the rest of the project!
If you would like to keep track of specific features, check out the bug tracker:
https://todo.sr.ht/~sircmpwn/aerc2
If you would like to keep track of specific features, check out the bug tracker:
https://todo.sr.ht/~sircmpwn/aerc2
I was looking at the git page and wondering where I could see discussion on features/bugs etc, I did not find it and was a bit frustrated.
I found out reading this comment that not only it has a todo page but it works great! Not sure if it's a design choice but perhaps making the resources accessible in a single page (e.g. like a project home) would be something worth of consideration.
I found out reading this comment that not only it has a todo page but it works great! Not sure if it's a design choice but perhaps making the resources accessible in a single page (e.g. like a project home) would be something worth of consideration.
Exchange compatibility? Asking for a friend;)
https://docs.microsoft.com/en-us/exchange/clients/pop3-and-i...
I have no interest in first-class exchange support upstream.
I have no interest in first-class exchange support upstream.
Can exchange do IMAP?
Yes
Then it 'supports' exchange. \o/
It can but whether it does depends on your local IT. Which means it doesn't.
In the video, it seems to be being pronounced “arc”. This is unfortunately confusable with a widely-deployed email authentication standard, ARC (http://arc-spec.org/). I suggest contemplating at least a different pronunciation (even without changing the name, the spelling is open to about four pronunciations of varying obscurity and cumbersomeness—none of which particularly suggest the spelling “aerc” when heard, I may add).
Hmmm, I'm not familiar with command line email clients but this looks cool. I wonder if I can use aerc in a bash pipeline? Say, to pipe email content from/to gpg?
You can't pipe emails into aerc (yet?), but you can definitely pipe emails out of aerc. The :pipe command is bound to | by default, so you can type, for example, |gpg --decrypt | less<Enter>.
Gnus has been great for me, but after about 40k+ (I stopped looking at the counts actually) messages in my Maildir, performance suffers for me (that is, if I start gnus from scratch it takes more than an hour and a half to open, with my entire Maildir in the page cache, and a huge amount of extremely fast memory). Notmuch doesn't seem to help at all, or if it would, it's hard to tell if it's configured correctly.
40k email? That sounds too much if it is for a single person. If you get 10 email per days for 10 years, you'd not get to 40k (35.6k).
My suggestion will be to clean your mailbox instead of finding a new client.
My suggestion will be to clean your mailbox instead of finding a new client.
> If you get 10 email per days for 10 years
I recall times (mid 2000's) when I was active in a bunch of open-source communities and mailing lists were the main way to discuss. Getting around 50 e-mail per day was normal.
I kept a lot of those discussions in my e-mail client for later reference, because the mailing list website had sub-par search function compared to Mozilla e-mail client I used at the time.
It's possible he's using it as an e-mail archive for mailing lists or something like that.
I recall times (mid 2000's) when I was active in a bunch of open-source communities and mailing lists were the main way to discuss. Getting around 50 e-mail per day was normal.
I kept a lot of those discussions in my e-mail client for later reference, because the mailing list website had sub-par search function compared to Mozilla e-mail client I used at the time.
It's possible he's using it as an e-mail archive for mailing lists or something like that.
Seems the number has also doubled. This Maildir starts about eight years ago IIRC, and there are now ~110k messages in it.
Some of that is mailing lists for sure, I'd say I respond to about ten direct emails (not from lists) per day. If I could use SMTP for IM, I'd probably do that too.
Some of that is mailing lists for sure, I'd say I respond to about ten direct emails (not from lists) per day. If I could use SMTP for IM, I'd probably do that too.
40k/year (or 110/day) is nothing when you are active on mailing lists (yes, some of us still use them). Rule of thumb was "when you hit 1000/day, consider unsubscribing some..".
That's a little odd -- I was using gnus with maildirs that size ten years ago and it wasn't so bad. nnmaildir backend for gnus, right? I remember something about increasing the emacs memory limit before garbage collection kicks in, too.
> I remember something about increasing the emacs memory limit before garbage collection kicks in, too.
That seems interesting, I'll look at that. If there's one thing I have, it is a lot of memory. I would be okay if my whole Maildir was mmapped, as long as that made gnus faster.
That seems interesting, I'll look at that. If there's one thing I have, it is a lot of memory. I would be okay if my whole Maildir was mmapped, as long as that made gnus faster.
(I have used Wanderlust on emacs for about 15 years now.)
I think using maildir directly may be hard to squeeze good performance out of with emacs. I'd suggest trying the alternatives: for eample, IMAP with ~30k messages should work decently in Wanderlust (and I would assume gnus), though initial load is slow (way less than hours, though). Using mu (maildir utils) via search in wanderlust to load 30k messages take about 1 minute, but if you are using mu you should be searching, not loading an entire mailbox. So there are probably some options out there, but I'd avoid loading 40k messages from a maildir directly.
I think using maildir directly may be hard to squeeze good performance out of with emacs. I'd suggest trying the alternatives: for eample, IMAP with ~30k messages should work decently in Wanderlust (and I would assume gnus), though initial load is slow (way less than hours, though). Using mu (maildir utils) via search in wanderlust to load 30k messages take about 1 minute, but if you are using mu you should be searching, not loading an entire mailbox. So there are probably some options out there, but I'd avoid loading 40k messages from a maildir directly.
Crashed on first email I read from Gmail. Also, I had to enable "less secure access" in Gmail for aerc to work. Will try again after a few months.
'Less secure' access is a choice by google to lock people onto gmail, they choose not to implement random device specific passwords.
Better to avoid gmail.
Better to avoid gmail.
How does it lock you in to gmail? They provide a method by which you can use any mail client if you'd like.
Applications can always implement OAuth 2.0, which is pretty open (and is what you'll need to do for other mail providers, not just gmail.)
Applications can always implement OAuth 2.0, which is pretty open (and is what you'll need to do for other mail providers, not just gmail.)
They took something that worked fine, then broke it after they had the majority of users. There are backwards compatible and secure methods (Like allowing a unique password per device). It is an obvious tactic to force people to choose between gmail web client, and outlook/thunderbird/aerc.
To make matters worse they falsely point the blame at competitors and then people like you defend them.
To make matters worse they falsely point the blame at competitors and then people like you defend them.
"less secure" nonsense is required for mutt as well.
How does this compare to mutt?
Mutt/Neomutt is much more mature and has more features and better performance. (fantastic threads support, fast and very flexible filtering, etc.)
Aerc is very new and written in Go. I tested it on my 100 thousnand mail ARM linux mailing list archive, accessed via localhost dovecot IMAP server, to see the best case performance, but it doesn't look good, atm.
It looks like this when I scroll through the archive: https://megous.com/dl/tmp/cjitwkaxpsypgcfdvncr.mp4
It's not really comparable to mutt, yet. The performance is slow, and it doesn't support threads, which is a must for MUA.
Aerc is very new and written in Go. I tested it on my 100 thousnand mail ARM linux mailing list archive, accessed via localhost dovecot IMAP server, to see the best case performance, but it doesn't look good, atm.
It looks like this when I scroll through the archive: https://megous.com/dl/tmp/cjitwkaxpsypgcfdvncr.mp4
It's not really comparable to mutt, yet. The performance is slow, and it doesn't support threads, which is a must for MUA.
aerc doesn't download all of your message headers upfront - mutt does. All that time you spend waiting for mutt to open your inbox is downloading all of the data that aerc is downloading as you scroll. Also, you can scroll faster with ^d/^u, half a page at a time, or pgup/pgdown, for a full page at a time.
Yes, aerc is not yet as featureful or mature as mutt, but it definitely does not have inferior performance.
Yes, aerc is not yet as featureful or mature as mutt, but it definitely does not have inferior performance.
I use POP3, and only wait for mutt when changing to a folder (4s/100k mails). Then everything is basically instantaneous.
But yeah, I don't know about mutt IMAP performance, as I never used it. I've only configured a local IMAP server over my maildir to be able to try aerc. I have no clue why aerc is taking 100-200ms to load a single message (as you see in the video) from the localhost. Maybe naggle (is it even used on localhost)?
Also, I'm not sure how you'd make threads work while loading message list only partially. So full load of the message list is needed anyway (at least once and cache it locally). It's not some failing. I want thread that started 5 months ago to pop forward if new message is posted to it.
EDIT: Faster scrolling loads multiple messages at once faster. Maybe aerc can take into account that user may have scrolled past more than one message in the time the previous message finished loading.
But yeah, I don't know about mutt IMAP performance, as I never used it. I've only configured a local IMAP server over my maildir to be able to try aerc. I have no clue why aerc is taking 100-200ms to load a single message (as you see in the video) from the localhost. Maybe naggle (is it even used on localhost)?
Also, I'm not sure how you'd make threads work while loading message list only partially. So full load of the message list is needed anyway (at least once and cache it locally). It's not some failing. I want thread that started 5 months ago to pop forward if new message is posted to it.
EDIT: Faster scrolling loads multiple messages at once faster. Maybe aerc can take into account that user may have scrolled past more than one message in the time the previous message finished loading.
I'm guessing the main problem is that I can't cancel an IMAP request once it goes out. When you scroll down, one at a time, through all of the messages like that, I have to wait for ones that scrolled offscreen long ago before I can read out the details for the ones onscreen now. Adding an option to fetch all headers when opening a folder might be wise, or just fetching the offscreen headers in the background while idle. Another thing some email clients do is open several IMAP connections, but pooling connections to implement cancellation could get icky.
aerc will also support maildir before 1.0, which doesn't have the same issue, and will be at least as fast as mutt.
>Also, I'm not sure how you'd make threads work while loading message list only partially. So full load of the message list is needed anyway (at least once and cache it locally). It's not some failing. I want thread that started 5 months ago to pop forward if new message is posted to it.
IMAP has a thread extension I intend to put to good use for this purpose.
aerc will also support maildir before 1.0, which doesn't have the same issue, and will be at least as fast as mutt.
>Also, I'm not sure how you'd make threads work while loading message list only partially. So full load of the message list is needed anyway (at least once and cache it locally). It's not some failing. I want thread that started 5 months ago to pop forward if new message is posted to it.
IMAP has a thread extension I intend to put to good use for this purpose.
> IMAP has a thread extension I intend to put to good use for this purpose.
I didn't know. Very nice.
I didn't know. Very nice.
With header caching opening a mailbox with mutt is massively improved. It takes only like 3-4s to open a 100k IMAP folder.
Pretty amazing! Some observations:
- Attachments that don't have a filter can't be visualized. For this case would be interesting to open with 'xdg-open' when hit <Enter>, and/or '.mailcap' support.
- Account password is stored in plaintext
- Occasional rendering artifacts when switching tabs/folders
If those above are fixed plus theming, unread, etc. I can easily see myself using it as my daily driver.
- Attachments that don't have a filter can't be visualized. For this case would be interesting to open with 'xdg-open' when hit <Enter>, and/or '.mailcap' support.
- Account password is stored in plaintext
- Occasional rendering artifacts when switching tabs/folders
If those above are fixed plus theming, unread, etc. I can easily see myself using it as my daily driver.
>Attachments that don't have a filter can't be visualized
You can use :save or :pipe on these, but yeah - xdg-open would also be cool. Mailcap support would also be great.
>Account password is stored in plaintext
In a chmod 600 file, though. There's also an option for configuring a command to run to retrieve your password by e.g. decrypting it with gpg: see aerc-imap(5), or :help imap, for details.
You can use :save or :pipe on these, but yeah - xdg-open would also be cool. Mailcap support would also be great.
>Account password is stored in plaintext
In a chmod 600 file, though. There's also an option for configuring a command to run to retrieve your password by e.g. decrypting it with gpg: see aerc-imap(5), or :help imap, for details.
It seems ':pipe' sends the data to stdin, I was trying to see a pdf file and the programs I tried (evince, mupdf) do not seem to support this (or perhaps usage is different?).
Seems like a good patch to implement a command that saves to a temporary file and opens with provided program, will certainly follow development, great work!
Seems like a good patch to implement a command that saves to a temporary file and opens with provided program, will certainly follow development, great work!
Is it groundbreaking to display mail with an external pager or to pipe it to filters? These were/are core features of elm, from 1986.
IMO the key innovation is that aerc does it with an embedded terminal emulator, tmux-style. This allows you to keep using the client for other things while reading or composing emails.
That is interesting and different. I guess I am accustomed to the "unix way": I use screen to multiplex my terminal and I have no bad problems from running multiple instances of mutt on the same maildir.
That workflow to me seems like more of a hack begging to be improved than a comfortable daily driver. I've never had a problem running mulitple instances of mutt, either - and I run multiple instances of aerc sometimes, actually - but since aerc has ownership over your emails and mail accounts it only makes sense to me that it would multiplex them for you.
I'd argue that the aerc approach is also bit of hack[1], but ultimately it mostly boils down to the limitations of terminals; to have "sub-windows", you need to implement basically a whole windowing system and terminal emulation layer.
Makes me think what would email client designed for and integrated with tmux look like, i.e. the client would open new tmux panes for editors etc.
[1] don't take that as a hard criticism, I happen to think lot of things, especially around terminals, being hacks.
Makes me think what would email client designed for and integrated with tmux look like, i.e. the client would open new tmux panes for editors etc.
[1] don't take that as a hard criticism, I happen to think lot of things, especially around terminals, being hacks.
Well, it's not as hacky as you portray it to be. The windowing system already needed to be there for other aerc features (and the embedded terminal is used in more integrated contexts than just windows, too). The terminal emulation is delegated to libvterm, the same library vim uses for this purpose. The actual aerc code is pretty simple:
https://git.sr.ht/~sircmpwn/aerc/tree/master/widgets/termina...
<500 lines.
https://git.sr.ht/~sircmpwn/aerc/tree/master/widgets/termina...
<500 lines.
It's interesting that these days it's quite easy to get into deep terminal emulator inception: xterm/Terminal.app/WSL -> tmux/screen -> vim and now aerc.
Very excited by the prospect of a modern terminal-mail client that is easier to use!
After following the README: this is clearly not ready/designed for wide consumption - the recipe neglects to mention how to install a custom doc-tool called scdoc (by the same author?) that is required to build it - and there are no pre-built binaries (that I can see).
After following the README: this is clearly not ready/designed for wide consumption - the recipe neglects to mention how to install a custom doc-tool called scdoc (by the same author?) that is required to build it - and there are no pre-built binaries (that I can see).
Most Linux distros already have scdoc available:
https://repology.org/project/scdoc/badges
It's not designed to be installed from pre-built binaries. It requires some other stuff to be set up on your system, too. It's designed to be friendly for distros to package instead. If you want to install it from source, use the Makefile like everything else.
https://repology.org/project/scdoc/badges
It's not designed to be installed from pre-built binaries. It requires some other stuff to be set up on your system, too. It's designed to be friendly for distros to package instead. If you want to install it from source, use the Makefile like everything else.
It’s still version 0.1
https://github.com/ddevault/aerc
> This repository is abandoned in favor of ongoing development on git.sr.ht. The codebase has been rewritten in Go and is much more stable and useful than what you see here.
@Sir_Cmpwn what's the advantage of git.sr.ht over github?
> This repository is abandoned in favor of ongoing development on git.sr.ht. The codebase has been rewritten in Go and is much more stable and useful than what you see here.
@Sir_Cmpwn what's the advantage of git.sr.ht over github?
That's his own site that he built himself. It runs a ton of services, bug trackers, CI, mailing lists, wikis, etc. https://sourcehut.org/
For one, he’s the lead dev on gir.sr.hr.
In terms of general benefits: email workflow is a big one for those that like it, it’s open source, no javascript, no tracking, and built in continuous integration and mailing lists.
In terms of general benefits: email workflow is a big one for those that like it, it’s open source, no javascript, no tracking, and built in continuous integration and mailing lists.
SourceHut is my own platform:
https://sourcehut.org
It's entirely open source (unlike GitHub), has its own CI, and is mailing list oriented instead of PR oriented.
https://sourcehut.org
It's entirely open source (unlike GitHub), has its own CI, and is mailing list oriented instead of PR oriented.
I can tell from the video that the interface is quite easy to navigate if you're a vim user. Very impressive work!
I just tried it and I love it! Mutt could never convince me because the configuration seemed overly complicated and I didn't like the controls.
Now maybe I'm just blind but I can't see a way to highlight unread emails in any way. Once I can get this working I'll switch in a heartbeat.
Now maybe I'm just blind but I can't see a way to highlight unread emails in any way. Once I can get this working I'll switch in a heartbeat.
Why account passwords are stored on plaintext after the wizard? How do you encrypt them while configuring?
Unless you are willing to provide a decryption key on every "check my email" call (eg. every 5 minutes), an email client (or well, anything requiring frequent reauthorization) virtually has to have it in "plain text" (or any obfuscated form which is equivalent to plain text).
Workable alternatives are to store the decryption key in memory for the runtime of the program (eg. using login keyrings or per-app logic).
If you encrypt your $HOME or your entire disk, storing it in plain text achieves roughly the same level of protection (eg. decryption key is in the memory).
Workable alternatives are to store the decryption key in memory for the runtime of the program (eg. using login keyrings or per-app logic).
If you encrypt your $HOME or your entire disk, storing it in plain text achieves roughly the same level of protection (eg. decryption key is in the memory).
man aerc-imap for details, you can specify an external command to run. The creds file is chmod 600, and most other email clients (e.g. thunderbird) are also storing your creds in plaintext - it's just less obvious cause they put them in sqlite or something.
How is this any improvement over mutt?
I can use mutt with emacsclient as my editor, in tmux.
I can use mutt with emacsclient as my editor, in tmux.
Some parts of mutt look like unmaintained and on life-support. I've seen the GPG interface code and it's full of deprecated code (e.g. PKA support) or subtle bugs.
Good job. Markdown support for sending html-Mails would be very nice ;)
Is there any way to add a new folder from aerc? I'm loving it (besides a bug with reddit emails) but that's a major bummer (as well as no manual "refresh" option)
As another point in the space, have you looked at nmh? https://www.nongnu.org/nmh/
Hmm why not mblaze[0] over aerc?
[0] https://github.com/leahneukirchen/mblaze
[0] https://github.com/leahneukirchen/mblaze
I find it funny that the first thing on their web site for a text-mode email client is a video screencast: as someone who likes spending time in text interfaces (terminal or emacs), it's exactly for the reasons videos are bad.
You can't skip-through videos to get to the part you care about which is obvious in a textual format (and it's obvious if it's even there). You can't copy and paste stuff. You usually have to have sound on to understand what's going on.
Sorry for ranting a bit about this modern tendency to record videos instead of write text :)
You can't skip-through videos to get to the part you care about which is obvious in a textual format (and it's obvious if it's even there). You can't copy and paste stuff. You usually have to have sound on to understand what's going on.
Sorry for ranting a bit about this modern tendency to record videos instead of write text :)
Thats neat. I aways wanted an text only email clientem easier to use than alpine and mutt. This on seens usable out of the box. I will take a look.
[deleted]
That looks promising! I wish Mutt had a mail account configurator like the one in Aerc. Definitely giving it a try.
I have to be skeptical of any email client that's not integrated in to Emacs.
What about integrating emacs into aerc? You can set your EDITOR to emacs and replace aerc's default keybindings with a more emacs-inspired set. Send me your binds.conf and I'll add it to contrib in case anyone else wants an emacs-esque setup, too!
"You can set your EDITOR to emacs and replace aerc's default keybindings with a more emacs-inspired set."
I appreciate the suggestion, but unfortunately that's not even remotely adequate.
By integration I mean exposing every single function and UI element of the client to Emacs, so that they can be bound, wrapped and extended as needed. Ideally, these functions would be written in eLisp, so they themselves could be modified and customized to taste while leveraging the enormous Emacs eLisp ecosystem.
Emacs email clients have this sort of integration, and it is what gives them tremendous flexibility and power.
I appreciate the suggestion, but unfortunately that's not even remotely adequate.
By integration I mean exposing every single function and UI element of the client to Emacs, so that they can be bound, wrapped and extended as needed. Ideally, these functions would be written in eLisp, so they themselves could be modified and customized to taste while leveraging the enormous Emacs eLisp ecosystem.
Emacs email clients have this sort of integration, and it is what gives them tremendous flexibility and power.
I'm not ignorant of how emacs works - I was just giving you a cheeky response to your cheeky comment.
You can also say that Gnus is slow, if you want to be extra cheeky. As currently configured, opening gnus on my (admittedly a bit large) Maildir takes more than an hour (no, really, I'm not joking); of course, once it's up I dare not close it, and that works out fine for me.
>You can also say that Gnus is slow, if you want to be extra cheeky.
gnus is not the only way to do email in Emacs. IME, it is the most bloated way to do it.
While I didn't like the tone of the person's comment, I do sympathize with him. I used various email programs (pine, mutt, Thunderbird, etc) for years - but all of them seemed to lack something, and the effort to add my desired features was too high. With Emacs, the barrier to customize my workflow is a lot lower. Now that I've been using Emacs + notmuch for mail for the last few years, it's really hard to motivate myself to try anything outside Emacs, and the feeling is much worse when it's something cool like this.
I even haven't bothered with alot, although it is notmuch based. I mean, is it trivial for me to make an Org mode TODO linking to an email while in alot?
gnus is not the only way to do email in Emacs. IME, it is the most bloated way to do it.
While I didn't like the tone of the person's comment, I do sympathize with him. I used various email programs (pine, mutt, Thunderbird, etc) for years - but all of them seemed to lack something, and the effort to add my desired features was too high. With Emacs, the barrier to customize my workflow is a lot lower. Now that I've been using Emacs + notmuch for mail for the last few years, it's really hard to motivate myself to try anything outside Emacs, and the feeling is much worse when it's something cool like this.
I even haven't bothered with alot, although it is notmuch based. I mean, is it trivial for me to make an Org mode TODO linking to an email while in alot?
If you want this level of integration with emacs, it seems like an emacs mail client would be better suited for your workflow...
As someone who doesn't want to completely throw away their workflow and muscle memory, I consider that a feature.
What a beautiful code! It's not that common nowadays.
This is great! More email clients are always welcomed. :)
Is there any way I can see the name of attached files?
This looks fantastic. Thanks!!
What the TL;DR; difference between Aerc and mutt?
Watch the video. Aerc is usable.
I currently use mutt and have no problems with it, what's the issue?
You don't want to hear, but I tried to use mutt with Gmail.
Does anyone use alpine?
It's good to know that the world's best email client is still a work in progress.
You did it! Congratulations! World's best email client! Great job, everybody!
Dont really see the need for a new email client, we already got Mutt, sup, alpine and a few others.
[deleted]
* 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.