2021-05-16 12:19:45, Anton Khirnov <anton@khirnov.net> wrote:
> Thought I'd share with the people here the fork of alot I've been
> hacking on for the past ~1.5 years, see if there is any interest in it.
> The code can be found at git://git.khirnov.net/alot.

This looks very promising, and at least for me personally it is very
interesting. I tried it, and for my workflow at least it seems to work
as a drop-in for the mainline alot version. The only thing I have
noticed that broke was the now unnecessary ANSI-coloring I used in
mailcap scripts as a workaround to get rudimentary quote coloring.

I have been using sup/notmuch/alot (and forks thereof) for the last
decade or so, and I am very grateful for the work people have put into
this notmuch ecosystem of MUAs. None of the UIs have ever been perfect,
but that is okay, because for me at least most of them are still much
better than the alternatives (e.g. mutt, GMail, Thunderbird, Zimbra).


> - quoted blocks [...]
> - [...] thread mode is split-window

This new view is very nice, and for large threads (especially ones with
deep reply indentation) splitting it up like this gives a much better
overview of the threads than alots indented tree view.

> - all the parts are rendered for multipart/mixed messages, as per the
>   RFCs
> - encrypted/signed parts are now wrapped in a frame that indicates which
>   bits of the message are actually encrypted or signed

But I actually think this new way of dealing with multipart messages is
the most novel feature. It should be mentioned that mainline merged in a
similar togglemimepart/tree feature about a year ago (i.e. later than
where you forked), but this seems to be a more thoughtful design. This
is actually the first UI I have seen that intuitively presents the
different parts of complicated mails.


> - various architectural restructurings which were needed for the above
>   or to allow for future changes (I have a large TODO list left)

I for one at least would be very interested in hearing what sort of
feature you plan in the road map ahead.


> At this point my tree has over 200 new commits and some ~4k changed
> lines, so it's looking increasingly unlikely that I'll ever find the
> free time and motivation to upstream it -- especially given alot's
> glacial pace of development recently. If people are interested in using
> this, I'll probably fork it "properly" under a new name.

I really get this. I too have custom forks of e.g. alot tweaking small
annoyances in ways often considered more hacky than production ready.
For me at least these are tools I am using all day, so if I end of
supporting whatever fork I settled on for my own use long after the that
fork / the mainline dies away, that is fine by me.

Regardless of what happens to this with regards the mainline alot, I
just want to point out how nice it is that we have notmuch as a shared
backend for all these UIs. This makes it so much easier to port between
them as newer alternatives pops up. It also means that none of the UIs
needs to be feature complete to be useful, because for e.g. features
people needs once in a blue moon, there is no problem having a tailored
UIs/CLIs around for dealing with those particular things.


Best wishes,

-- johs (Johannes Larsen), (+47) 41435451