Re: announce: my fork of alot
2021-05-17 14:55:57, Anton Khirnov wrote: >> > - commands themselves should probably be synchronous [...] to >> > prevent races where a later command conflicts with an earlier one >> >> Yeah, that race condition is a annoyance. Quitting alot helps at least. > > Did you actually hit it? I don't think I actually saw it happen more > than a couple times, but even so I'd like to fix it before adding more > async. Maybe not as a race condition, but out of habit I tend to try aborting prompts with Ctrl-C (instead of Esc), and that triggers this conflict you describe. -- johs (Johannes Larsen), (+47) 41435451 signature.asc Description: signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
Quoting Johannes Larsen (2021-05-17 14:32:12) > 2021-05-17 10:54:09, Anton Khirnov wrote: > > Here's my current roadmap: > > Lots if interesting features/fixes! Of course keep in mind that it's largely a wishlist, so don't expect these to be done - at all - any time soon - in this order > > - commands themselves should probably be synchronous [...] to > > prevent races where a later command conflicts with an earlier one > > Yeah, that race condition is a annoyance. Quitting alot helps at least. Did you actually hit it? I don't think I actually saw it happen more than a couple times, but even so I'd like to fix it before adding more async. > > > * running external commands in a separate tmux pane/terminal > > That is a good idea. Quitting the editor and using ";" to temporary > switching to another buffer (e.g. reading something elsewhere in a > thread) works, but is a hassle. [vim-dispatch] does something similar > for e.g. external compilation/tests from the editor, so maybe they > figured out some indicator for when tmux panes/windows completes. > > [vim-dispath]: https://github.com/tpope/vim-dispatch Seems that just periodically polls the pane list, which is suboptimal. Seems tmux has a 'wait-for' command that could be useful for implementing this. > > - properly handle focus switching between the thread tree and message body > > Mapping something to "move toggle" worked okay to switch focus between > these panes. Was kind of a surprise when scrolling within a message body > scrolled to the next message though. Yeah, that's a known bug and I'm sure I'll get to fixing it SomeDay(tm), since it's rather annoying. -- Anton Khirnov ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
2021-05-17 10:54:09, Anton Khirnov wrote: > Here's my current roadmap: Lots if interesting features/fixes! > - commands themselves should probably be synchronous [...] to > prevent races where a later command conflicts with an earlier one Yeah, that race condition is a annoyance. Quitting alot helps at least. > * atomic complex retagging commands > e.g. add+remove in the same command sup had something like that. The retag operation when you had multiple messages used +/- prefixes to add/remove tags from those messages whilst leaving other tags on them untouched. I do not know if this was atomic, but at least it was idempotent. > * running external commands in a separate tmux pane/terminal That is a good idea. Quitting the editor and using ";" to temporary switching to another buffer (e.g. reading something elsewhere in a thread) works, but is a hassle. [vim-dispatch] does something similar for e.g. external compilation/tests from the editor, so maybe they figured out some indicator for when tmux panes/windows completes. [vim-dispath]: https://github.com/tpope/vim-dispatch > - search+highlight Yeah, I am still automatically trying "/" in alot (the hotkey that searched like that in sup) to search in the buffer. > - properly handle focus switching between the thread tree and message body Mapping something to "move toggle" worked okay to switch focus between these panes. Was kind of a surprise when scrolling within a message body scrolled to the next message though. > - pipeto refactoring Yeah, as it is now I only use it with less to read the raw body. I think pipeto based on a selected body/attachment for instance would be useful. -- johs (Johannes Larsen), (+47) 41435451 signature.asc Description: signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
Quoting Michael J Gruber (2021-05-17 09:33:13) > Patrick Totzke venit, vidit, dixit 2021-05-17 09:08:31: > > ``` > > [~] git clone https://git.khirnov.net/alot.git > > Cloning into 'alot'... > > fatal: unable to access 'https://git.khirnov.net/alot.git/': server > > certificate verification failed. CAfile: none CRLfile: none > > [~] git clone git://git.khirnov.net/alot.git > > > > Cloning into 'alot'... > > > > (times out) > > ``` > > It is unauthenticated git protocol: > > git clone git://git.khirnov.net/alot.git > > I can fully understand why someone wants to host their personal stuff > for themselves. I still don't understand why a git-fork of a > github-project which asks for upstreaming or collaboration is not at > github - and yes, you can 's/github/yourchoice/' in that sentence ;) Because at this point it is still "my personal stuff". If and when it actually becomes "upstreaming or collaboration", I can also push it elsewhere, as needed. I am not super fundamentalist in my religion. But for the time being I see no big difference between people cloning from my git server vs people cloning my repo on github. -- Anton Khirnov ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
Quoting Patrick Totzke (2021-05-17 09:08:31) > ``` > [~] git clone https://git.khirnov.net/alot.git > Cloning into 'alot'... > fatal: unable to access 'https://git.khirnov.net/alot.git/': server > certificate verification failed. CAfile: none CRLfile: none no HTTP(S) cloning set up, sorry > [~] git clone git://git.khirnov.net/alot.git > > Cloning into 'alot'... > > (times out) this should work, unless you managed to trigger my firewall's autoban (cleared it, just in case) -- Anton Khirnov ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
``` [~] git clone https://git.khirnov.net/alot.git Cloning into 'alot'... fatal: unable to access 'https://git.khirnov.net/alot.git/': server certificate verification failed. CAfile: none CRLfile: none [~] git clone git://git.khirnov.net/alot.git Cloning into 'alot'... (times out) ``` Quoting Patrick Totzke (2021-05-16 19:23:58) > Quoting Anton Khirnov (2021-05-16 18:47:24) > > > Quoting Patrick Totzke (2021-05-16 17:41:49) > > > Hi everyone, > > > > > > All this sounds very exciting and I'd be very happy to see these features > > > in > > > (mainline) alot! > > > > > > I agree that some of alot's underlying code is ready for refactoring > > > and urwid in particular has been a big drag on quickly implementing > > > things. > > > Also, I'd be interested in hearing your thoughts on deprecating some > > > "unworthy" > > > features in order to reduce the maintenance effort! > > > > That is largely a matter of perspective and personal preference. E.g. > > among the things gone in my tree are: > > - removing messages - I dropped that because I considered that code > > potentially dangerous, had no use for it myself, and just didn't want > > to tiptoe around it; someone actually using RemoveCommand in their > > workflow would have a different opinion > > Yep, same here. I never used that. > > > - switching to split-window layout for thread view made it simpler to > > implement quote folding, but also made sense to me since I never want > > to see more than one message at once; > > again, someone who prefers collapsing messages would see this as loss > > of functionality > > > > https://xkcd.com/1172/ is very much in effect > > This could have been easily introduced as a separate type of buffer to keep > both variants > without breaking things. > > > > > > > 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? > > > > > > > > > Yes, the speed at which alot progresses is borderline problematic. This > > > is of > > > course down to the small number of core contributors and the fact that > > > for all > > > of us life goes on an priorities change. > > > > > > One problem is that the project attracts many users interested in pushing > > > what > > > I'd call "hotfixes" to address missing features: Often people would > > > present > > > a (nicely working) proof-of concept that is not well documented, tested, > > > and > > > doesn't adhere to common code conventions, only not to follow up on their > > > promises to "clean things up", for all too understandable reasons. > > > Still, I believe that just merging everything will quickly kill the > > > project as > > > a) this leads to code that is very difficult and time-consuming to > > > maintain and > > > b) broken features are very damaging to user's perception of the > > > software, much > > > more so than missing ones. > > > > > > I am not accusing you of anything here, Anton. I just wish to point out > > > potential long term difficulties and clarify that I tried to err on the > > > side of > > > cautiousness to keep alot afloat in a usable state for most (potential) > > > users. > > > > You would be very correct to accuse me of taking various shortcuts. I > > would not call my changes "hotfixes", as I tried to keep continuous > > future improvements in mind > > I understand. The question is just how long do you plan to stick around > to add improvements and provide support? If your answer is: "not at all, I'm > only sharing my code here", then don't be surprised if your efforts die the > same death and quickly disappear as so many other notmuch projects before. > If you are fine with that: great. But I suppose you wouldn't have shared your > code here unless you'd want people to join in and use it (for longer than > a day). > > > (and in fact see many of my changes as > > cleanup and simplification). > > I'm more than happy to push some of them. > > > But I did make an explicit decision to > > prioritise rapidly adding new functionality, at the cost of potential > > regressions and loss of some features I di
Re: announce: my fork of alot
2021-05-16 12:19:45, Anton Khirnov 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 signature.asc Description: signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
Quoting Patrick Totzke (2021-05-16 17:41:49) > Hi everyone, > > All this sounds very exciting and I'd be very happy to see these features in > (mainline) alot! > > I agree that some of alot's underlying code is ready for refactoring > and urwid in particular has been a big drag on quickly implementing things. > Also, I'd be interested in hearing your thoughts on deprecating some > "unworthy" > features in order to reduce the maintenance effort! That is largely a matter of perspective and personal preference. E.g. among the things gone in my tree are: - removing messages - I dropped that because I considered that code potentially dangerous, had no use for it myself, and just didn't want to tiptoe around it; someone actually using RemoveCommand in their workflow would have a different opinion - switching to split-window layout for thread view made it simpler to implement quote folding, but also made sense to me since I never want to see more than one message at once; again, someone who prefers collapsing messages would see this as loss of functionality https://xkcd.com/1172/ is very much in effect > > > 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? > > > Yes, the speed at which alot progresses is borderline problematic. This is of > course down to the small number of core contributors and the fact that for all > of us life goes on an priorities change. > > One problem is that the project attracts many users interested in pushing what > I'd call "hotfixes" to address missing features: Often people would present > a (nicely working) proof-of concept that is not well documented, tested, and > doesn't adhere to common code conventions, only not to follow up on their > promises to "clean things up", for all too understandable reasons. > Still, I believe that just merging everything will quickly kill the project as > a) this leads to code that is very difficult and time-consuming to maintain > and > b) broken features are very damaging to user's perception of the software, > much > more so than missing ones. > > I am not accusing you of anything here, Anton. I just wish to point out > potential long term difficulties and clarify that I tried to err on the side > of > cautiousness to keep alot afloat in a usable state for most (potential) users. You would be very correct to accuse me of taking various shortcuts. I would not call my changes "hotfixes", as I tried to keep continuous future improvements in mind (and in fact see many of my changes as cleanup and simplification). But I did make an explicit decision to prioritise rapidly adding new functionality, at the cost of potential regressions and loss of some features I did not need. And again, this is a matter of perspective. If alot does what you want it to do then of course you will value stability and consistency. But if the lack of certain features makes it barely usable, then it makes sense to be more radical. > > > 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? > > 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 share Michael's concerns about further splintering the small group of > developers and believe that this would be to the detriment of both projects. > > It's no secret that I am ready to give the helm to others. I have been > maintaining this project for a while now, mainly for personal usage and as > a fun distraction. I have tried to squeeze in time to re
Re: announce: my fork of alot
Hi everyone, Of course I feel obliged to chime in and clarify, so here it goes. Quoting Michael J Gruber (2021-05-16 12: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! First of all many thanks to Anton for his enthusiasm in pushing the alot project further! > > The code can be found at git://git.khirnov.net/alot. > > Any particular reason why this is not a fork where upstream is (GitHub)? > > > 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! > > > 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. Especially if you go for "disruptive" > changes it's important to get the new architecture correct right from > the beginning. > > > I removed some features which I considered an > > impediment to progress and not worth the maintenance effort - YMMV. All this sounds very exciting and I'd be very happy to see these features in (mainline) alot! I agree that some of alot's underlying code is ready for refactoring and urwid in particular has been a big drag on quickly implementing things. Also, I'd be interested in hearing your thoughts on deprecating some "unworthy" features in order to reduce the maintenance effort! > > 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? Yes, the speed at which alot progresses is borderline problematic. This is of course down to the small number of core contributors and the fact that for all of us life goes on an priorities change. One problem is that the project attracts many users interested in pushing what I'd call "hotfixes" to address missing features: Often people would present a (nicely working) proof-of concept that is not well documented, tested, and doesn't adhere to common code conventions, only not to follow up on their promises to "clean things up", for all too understandable reasons. Still, I believe that just merging everything will quickly kill the project as a) this leads to code that is very difficult and time-consuming to maintain and b) broken features are very damaging to user's perception of the software, much more so than missing ones. I am not accusing you of anything here, Anton. I just wish to point out potential long term difficulties and clarify that I tried to err on the side of cautiousness to keep alot afloat in a usable state for most (potential) users. > > At this point my tree has over 200 new commits and some ~4k changed > > lines,
announce: my fork of alot
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. The code can be found at git://git.khirnov.net/alot. 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) 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 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. 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. -- Anton Khirnov ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
