It’s super impressive how much good sofware /u/SirCmpwn has been pushing out lately.
I would love him to sit down and explain how he is able to do all this, or his thought process or something. I cannot believe his level of productivity.
This is the work of 16 authors over the course of 2 years […]
This is the work of 16 authors over the course of 2 years […]
I came here to say the same… guys hammering out projects like there’s no tomorrow.
In the long run, there isn’t.
Not sure how to interpret this; either you’re just humble and don’t realize how many people really like the work you and the people contributing to them are doing, or you know something about the end of days and when they’re coming.
I’m off-contract at the moment, so I’m going to try aerc with the protonmail bridge and see how it goes and possibly see if I can contribute some code if I can tackle some of the low-hanging fruit as I’ve been waiting for a terminal mail client that’s non-intrusive for a long time and even had a couple half-hearted starts at building my own.
If he’s taking a stoic bent, memento mori, or always remember that you may die tomorrow.
“How do you write like you’re running out of time” - Line from the musical “Hamilton”
Yes, it’s truly impressive. I go to work full time, play in a sports league, and college part time and I think I’d have to quit all three activities to match his output.
Even then, I’m doubtful.
I don’t get why the integrated terminal emulator/multiplexer is presented as a feature (the first in the list, even). Surely having yet another multiplexer implementation (see also: vim) with its own idiosyncrasies and key bindings is not a good thing, and it would be better design to expose some IPC or configuration so that a user could integrate their own preferred terminal emulators (standalone windows, tmux panes…), or even more traditional GUIs (like gedit).
I think it’s an obvious solution that’s simply more intuitive and less complicated than what you describe. Also, it would otherwise be hard to keep the rest of the interface visible while editing/viewing e-mails.
@SirCmpwn great work! What do you think about:
JMAP -> I don’t like it but I’d take the patch
Autoencrypt -> I think this is better solved by the MTA
Thanks for the replies.
I’ve read both specs (JMAP and Autocrypt), well, skimmed them. I hope you won’t mind my opinion too.
JMAP has really ugly JSON interface, too bad they didn’t use REST so that e-mails could be nicely represented as URLs but I get that they want to squeeze performance out of it (for mobile devices).
Autocrypt wants to bring encryption to the masses but has some critical flaws for some security-oriented folks. For example keys distributed in headers replace keys in local keyring. So Autocrypt is broken if active attackers are in the loop but as far as I get PGP it’s exactly what PGP was designed for.
I’m a happy swaywm user. I setup mutt a long time ago but never used it so naturally I’m excited to give this a go. At this rate, in ten years, drew will have written everything running on my computer lol
As a long-time mutt user, I was a bit dismayed when “something” changed wrt how html email is viewed. I have to read a dump now, instead of it opening a browser.
This is probably configurable (in mutt) if I had time or could be arsed, but it would have been nice to see aerc doing something like that in action instead of just sending mail.
Also kinda sucks, in mutt, that now replying to html email, it uses the dumped html part in the reply, rendering the messages ugly.
I think you just need to fiddle with your mailcap settings. In my case, I get a best effort from some HTML rendering script, but when this doesn’t work I have a hotkey to load the current HTML part in Chrome.
You can this stuff in my dotfiles.
Adding this to your .mailcap file might help:
text/html; lynx -force_html %s; needsterminal
This did nothing, and set mailcap_path tells me I should be ok path-wise.
I had to add auto_view text/html to get anything out of this, and it uses elinks -dump, so maybe that’s yet another conf option.
This all ties into an annoyance I have with mutt: it’s kinda old and distros ship packages like neomutt and mutt-patched and all my woes might just be neomutt magic I can’t be arsed to deal with.
Deleting the mailcap now as useless :(
Huh, interesting, this is all I have in my mutt config files. I do have this, though:
That’s the only other thing I can think that might affect it.
I stopped using mutt because it was very slow after I set up RE filtering.
Is it just me, or is “the world’s best email client” not the worlds best tagline?
It’s patently false as that title has already been claimed by mu4e ;-)
As a constant MUA tinkerer (as many of us are, I’m guessing) I’m thrilled to see new ideas in this space! Can’t wait to try this one.
It’s better than mutt’s tagline: “All mail clients suck. This one just sucks less.”
I actually rather like that tagline. Sort of a “better the devil you know” kinda thing
I’ll definitely give this a shot. My current setup is mu4e and mbsync, so I can try new clients with ease, as long as they understand Maildirs. I’m always looking for a better mail experience, which sort of dates me, as I still prefer it as a medium of communication to Slack, IRC, Signal, Messages, &c.
So, this title is a joke, right?
Now, I use Emacs as my mail client, but it’s not really cute to see some project claim it’s ’‘the world’s best’’. How many people could have their project on this website with a claim like that and not be considered egotistical at best and spam at worst?
It’s okay. You were right first time.
How can “the best” without a specific criteria for being “best” ever be taken seriously? There is no “best”.
hmm, it actually looks like the dev has overlapping wishlist I have as a mutt user. Been thinking about writing a new mail client myself… well I might not have to, but I still want to, so I probably will :P but aerc does look nice.
All I really want is to be able to read about a thousand new emails a day (none mailing lists), and handle an open mailbox with five+ years of this rate of mail accumulation (I don’t believe in inbox zero)
hah nice, yeah I get ~200 emails a day (though I frequently only need to actually act upon about 20 of them) and tend to accumulate about a dozen a day that I don’t delete. Right now I have 2,954 messages in the box. mutt does a fine job. While I can imagine better, it is basically good enough. A lot of people are amazed when I say I can actually look at each one of those hundreds too, but it isn’t that hard with a decently configured clienst.
It’s mostly hard when mutt takes over 60 seconds to load the main view.
How is the email stored? I’ve noticed this too as I still use mbox format for storing emails, and mutt has to parse through the entire file to build the index display. I suspect swithing to mdir format might make it faster, but I’ve been too lazy to test that.
Oh. Well then …
It’s the mandatory listing of everything in the mailbox that makes it slow. If it paginated at, e.g., 1k messages, then it could be far faster.
I’m really excited about this project, but it appears that the build is currently broken. Do you have a stable release?
git clone https://git.sr.ht/~sircmpwn/aerc
Cloning into 'aerc'...
go build \
-ldflags "-X main.Prefix=/usr/local" \
-ldflags "-X main.ShareDir=/usr/local/share/aerc" \
worker/imap/worker.go:115:29: w.worker.Logger.Writer undefined (type *log.Logger has no field or method Writer)
You need go 1.12 or newer.