First of all - thank you for your email. I am happy to get feedback.

Quoting Michael J Gruber (2021-05-16 13:15:28)
> Anton Khirnov venit, vidit, dixit 2021-05-16 12:19:45:
> > Hi,
> > 
> > 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.
> 
> Thanks for sharing!
> 
> > The code can be found at git://git.khirnov.net/alot.
> 
> Any particular reason why this is not a fork where upstream is (GitHub)?

Religious reasons mainly.

I dislike unnecessary centralization and prefer to run my own services
where feasible. Since I already run a git server for other things, it
was simplest to use it for alot as well.

>  
> > There are many changes in various places, the most user-visible ones in
> > the thread view mode. Specifically
> > - quoted blocks in the email body can now be colored and folded (this
> >   was probably my main motivation for starting all this)
> > - in upstream the thread mode shows a tree of messages, each node in the
> >   tree is a rendered message, that can be collapsed into a single-line
> >   summary;
> >   in my fork the thread mode is split-window - upper window for the tree
> >   with the thread structure, lower window for the currently selected
> >   message; no collapsing of messages
> > - attachments can be rendered inline, possibly colored with pygments
> > - git patches are colored with pygments
> > - 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
> > - various architectural restructurings which were needed for the above
> >   or to allow for future changes (I have a large TODO list left)
> 
> This all sounds like getting closer to mutt's view, which is not a bad
> thing at all!

I used to use mutt in my computing pre-history (before discovering
notmuch over 10 years ago), so it's quite possible that was my
inspiration. Even though I barely remember what it looked like.

> 
> > The code is currently alpha quality - I am using it as my main MUA and
> > it works for my workflow, but any features I don't use regularly may be
> > broken. There is a general lack of "UX" polish (appearance and
> > documentation). I didn't bother updating the test suite to keep up with
> > all the architectural changes (plan to get to that once I consider the
> > code more stable).
> 
> I have to question this strategy. alot (upstream) suffers from a lack of
> tests already. There is really no point writing tests after the fact or
> once you discover bugs by chance.

Why "no point"? Adding tests is (almost) always good, whatever was the
trigger for writing them.

While I certainly agree that a comprehensive test suite is very
important for preventing regressions, there is a tradeoff between the
amount of time/mental effort I can spend on this and what the gain is
for me. I just don't find writing tests to be much fun, so forcing
myself to maintain the tests properly would slow down my progress quite
a lot.

I chose to implement the features I need first, and handle testing
later. You may judge me for it, but in the end what's most important to
me is how well this fulfills my requirements for a mail client.
Also, patches welcome ;)

> Especially if you go for "disruptive" changes it's important to get
> the new architecture correct right from the beginning.

I don't quite follow the reasoning here. Automated regression testing is
most useful for catching regressions. It is not that much useful for
guiding architecture design.

> 
> > I removed some features which I considered an
> > impediment to progress and not worth the maintenance effort - YMMV.
> > 
> > Why did I not submit all this as PRs to upstream alot? The main reasons
> > were my lack of time and disagreement with the upstream about project
> > status. From what I can tell, alot maintainers consider the project to
> > be mature, so they prioritize stability and small incremental changes.
> > From my perspective, alot is lacking some critical features -- some
> > implemented in my fork already, some planned -- which makes it
> > borderline-unusable for me. As implementing those features required
> > large-scale architectural changes and my free time was quite limited, I
> > prioritized quickly implementing the things I cared about over
> > progressing in small incremental stable easily-reviewable steps.
> 
> I have a similar impression about the project status. I'm curious: What
> are the architectural changes that you made?

It would be nontrivial to list them comprehensively, but off the top of
my head:
- urwidtrees is gone (this was a major obstacle to implementing quote
  handling IMO)
- thread tree structure is now fully decoupled from presentation
- stronger boundaries between various components (e.g. no more accessing
  email objects directly)
- removed some assumptions about emails that do not always hold
    * a signed/encrypted email is signed/encrypte in its entirety;
      actually this only holds on a MIME-part basis
    * a mail has one 'main' part that is to be displayed to the user as
      'the body'
      actually the body intended for display can be a concatenation of
      any number of MIME parts

> 
> From any notmuch-based MUA I expect a clear correspondence with
> underlying notmuch concepts, such as "notmuch search results" being a
> set of messages (not threads) and therefore command acting on that set
> by default.
> 
> alot always confuses me in this regard.

I'm afraid I disagree on this point. IMO one of the great points of
notmuch is its flexibility - it provides you with a versatile toolkit
that can be adapted to your workflow, rather than you adapting to
someone else's idea of what things should look like. E.g. my way of
working with emails is primarily thread-based, there is less focus on
individual emails. I would actually pefer alot to be _more_ thread-based
- e.g. when tagging in search mode.

That said, I see no fundamental reason you couldn't have both in alot
(or its hypothetical platonic ideal).

> 
> > 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.
> > 
> > Any comments or questions are very much welcome. I can also be reached
> > on IRC as elenril.
> 
> Have you tried raising these concerns with upstream before your fork?

1. I did submit a small number of patches to alot. The process was not
hugely satisfactory and left me with the impression that implementing
the features I want "the proper way" would require more time and effort
than I'm willing/able to spend.

2. E.g. folding quote blocks is issue number 3 in alot, opened in 2011.
Since then several people tried to work on it, but no attempt was
ultimately successful.

> Have you tried gathering a team around an idea and starting something
> new together?
> 
> Frankly, upstream is borderline small already, and the way you started
> your fork probably will not attract a team of people who want to make
> that new fork their (common) own or are looking for a stronger team.

I am way more of a "write code" person than "gather a team" person.
Writing this code was fun, improved my email workflow, and got me more
experience in new areas. That makes it worthwhile by itself.

Making it into a sustainable project used by others (either by merging
into alot or branching off into something new) would be nice, but is not
a necessary end goal for me.

> the way you started your fork

The way I see it, I have not started anything yet. I wrote some code for
my personal use and now I'm trying to gauge if others might be
interested in it. If yes, we'll see what ways forward are available. If
not, it's perfectly viable for me to just maintain it myself.

One very nice thing about alot is that it's really compact - since so
much of the heavy lifting can be done by notmuch, urwid, or the python
stdlib. It's very much possible for one person to get a decent
understanding of the entire codebase.

> 
> Incidentally, just yesterday I looked at neomutt's status, in search of
> a substitute for alot with good notmuch support and a stronger devel
> community. I suggest you read the most recent posts on their devel list
> to see how much the deviating fork has burned out a small team.

I get your point, but I see no perfect solutions here. I've been using
alot since 2014, hoping that it would at some point gain the missing
features. That never happened and its rate of development gradually slowed down
to almost nothing. I also stopped being a forever student, so using
email efficiently became a bigger priority for me.

My options were switch away from notmuch (see no better alternatives),
switch to a different notmuch frontend (of which I didn't see many,
especially as I'm a vim user), or try to improve alot. The last option
led me here.

-- 
Anton Khirnov
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org