From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id opCLFYYWomB2SwEAgWs5BA (envelope-from ) for ; Mon, 17 May 2021 09:08:54 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 6JGsEIYWomDHGgAA1q6Kng (envelope-from ) for ; Mon, 17 May 2021 07:08:54 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B4C351CFFD for ; Mon, 17 May 2021 09:08:53 +0200 (CEST) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 9070529054; Mon, 17 May 2021 03:08:44 -0400 (EDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by mail.notmuchmail.org (Postfix) with ESMTPS id 9B8B229000 for ; Mon, 17 May 2021 03:08:42 -0400 (EDT) Received: by mail-wr1-x42e.google.com with SMTP id r12so5204456wrp.1 for ; Mon, 17 May 2021 00:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:to:in-reply-to:references:date:message-id :user-agent; bh=pM/PmQGdDtJSQdPT/wqVagZgHdKUWWw+/dWdYKaFIlU=; b=R6IHi2TvCTWNx+TsEzm5jjtp3IWEP8BD+tvUSweW0kftO+d1X+KLFIMxrKvPDKiuef 8ESpcc0qZYeuVkUQAoN3w787kY1vDylf0qh/SZlG6Xh0ttTGYIIayjijEhkkCtt12fj/ pMFFJd+9IVz01T+RSMxRPnhxVrmA5f7pxR6fH3mm/tWQyjsNRNhK1GlL50wyxfM1lQ2Q vD+3TI+ocp2jmWeYfVbl3KGXMFk99lOBUPt9VCQ2dFfqPspu/mInEHO+CoRvVAcvqVQk dXNfWFrkIKpn9t3e+lOl8WD4pnE0/yuv1quLG5E3tsh/qZnJktL2pSWcnb52Nf4yZeyL 3V9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:to:in-reply-to :references:date:message-id:user-agent; bh=pM/PmQGdDtJSQdPT/wqVagZgHdKUWWw+/dWdYKaFIlU=; b=Cm+WOdOHOQZMSZeGEhGQ5+DnseAPTsB9vZaHapPLXgj2792gbDUxdFtJ43FcwweSkN PvJpUC4zdM5qwHM1q0I5fyKP01oed0nx0Ei2C2PyQ6uIdCTybasaYosnDfxUX67Fixwf FKmfPsJbSledkbL5s3FxiB8Yn3ieP8A70nSfSkXzcS+6PEU0NS0LAHXVrqD0xPD7dj2W G7CjiGQoIJCqgUAjXWGBj7lnZc6oVucyfFvV9iOeOQdKIeE5dv1Xx1mCyh7ZT2G3jaPK aYuSbzGsXjVOP+2R4VJdOMHzkLxowSEaurkAhVECXSI0bsjOltHqbSKz/V3nI/MJQ07q FK/Q== X-Gm-Message-State: AOAM530UhgUDLmOUFohgIRqGmqtgpAQ+A7l73pLZ6opLuGJJOxoS2fLy ppx5Sm4R99EREjy21uC0vlg= X-Google-Smtp-Source: ABdhPJxY3eO3DWvITDHBedy+nGSNgbsxxxhG6psxV3m9AeIIS6P8F5pCFT8TC8E/4brD5PlgwWp0mQ== X-Received: by 2002:a5d:4843:: with SMTP id n3mr18618972wrs.411.1621235314101; Mon, 17 May 2021 00:08:34 -0700 (PDT) Received: from localhost (0.2.a.7.9.f.b.3.5.1.d.5.a.1.9.8.4.3.5.d.1.c.a.7.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:7ac1:d534:891a:5d15:3bf9:7a20]) by smtp.gmail.com with ESMTPSA id i1sm11675847wmb.46.2021.05.17.00.08.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 May 2021 00:08:33 -0700 (PDT) MIME-Version: 1.0 Subject: Re: announce: my fork of alot From: Patrick Totzke To: Anton Khirnov , Michael J Gruber , notmuch@notmuchmail.org In-Reply-To: <162118943864.470262.9109053349416524142@piu> References: <162116038546.29687.12722695687857643272@lain.red.khirnov.net> <162116372803.55588.12574083715280154635.git@grubix.eu> <162117970935.470262.11733111308148672432@piu> <162118724451.29687.13284058079630704324@lain.red.khirnov.net> <162118943864.470262.9109053349416524142@piu> Date: Mon, 17 May 2021 08:08:31 +0100 Message-ID: <162123531198.470262.5054992432062639445@piu> User-Agent: alot/0.9.1 Message-ID-Hash: 2YBGZ5Q7B4B25ILJNXAOHSZB4KLXTJY6 X-Message-ID-Hash: 2YBGZ5Q7B4B25ILJNXAOHSZB4KLXTJY6 X-MailFrom: patricktotzke@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: multipart/mixed; boundary="===============0360871726466199874==" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1621235333; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=8Qoz7VrB77A63d3Dps6aJwbuQEkYPGy/GhqGIeEqYQo=; b=Y1rnoU7FQXuaDJHG1YN3nEHFgKbBO1wJS9ApDz3B2RpBqZCrbuJjy0egUnZ+HYzzwHYL0j lbaUVQvyZtZnbgHxJePiVRzvw8sBmrsT+BUGFvbvyeYK8BwG1PQM0zMVjF1K+yCzz06spk PL83R74bxA+aFkguuhs8cBwQbrLrA2ojdoeobKetu9XIugAgiQK9UIzyES4VkBausyImeg G8eFpxLqmT8vPpaSEX+YCUYFggF7v5MsZUlOPT7+MlLo/IxGXOK2YnMOM8k/Qzt2iswMif FwRreRmgu89TtMbiPuXgEkvf0V0h1aO8cUyQ47YFMm4MJznD8tCJAlLCAxxRGw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1621235333; a=rsa-sha256; cv=none; b=h6Be/0boSrNS6LWTVgy8hkGNyM1SIFNj1f2OaA2Qf5Q9dZ5Z+InWqXhBc1QMZiTYkchr8h MeZt/ROuGIVFF+aUjG7+mWlHr53bwm0bzoqRae6QlB/U+VcqsdKOso0tmCEQVJkRcYRyzv BppF45ffsSpvvvWRf5lr6I5u0lc8uu6CNlVA4booS+bD1HYbZTSUbuUZ7IHxa8/rv+B0ha /Hl2CSIH0H8icIfkyEmObeE/8RnRj4vXojcmjJL1OVJp3FZ4aCpzY5ZMR6F1AFAwuJnKtt KAUb2vpuf5+a7hm+IFUNAYa3Eg0zBtO+iRPUx8CM/W1mDT6UqoBzngK2gtxynA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20161025 header.b=R6IHi2Tv; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: 0.53 Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20161025 header.b=R6IHi2Tv; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: B4C351CFFD X-Spam-Score: 0.53 X-Migadu-Scanner: scn0.migadu.com X-TUID: tzumAM6myFZh --===============0360871726466199874== Content-Type: multipart/alternative; boundary="===============6946972824496193216==" --===============6946972824496193216== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ``` [~] git clone https://git.khirnov.net/alot.git =20 Cloning into 'alot'... =20 fatal: unable to access 'https://git.khirnov.net/alot.git/': server certifi= cate 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) >=20 > > Quoting Patrick Totzke (2021-05-16 17:41:49) > > > Hi everyone, > > >=20 > > > All this sounds very exciting and I'd be very happy to see these feat= ures in > > > (mainline) alot! > > >=20 > > > 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 t= hings. > > > Also, I'd be interested in hearing your thoughts on deprecating some = "unworthy" > > > features in order to reduce the maintenance effort! > >=20 > > 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 >=20 > Yep, same here. I never used that. >=20 > > - 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 > >=20 > > https://xkcd.com/1172/ is very much in effect >=20 > This could have been easily introduced as a separate type of buffer to ke= ep both variants > without breaking things. >=20 >=20 > > > > > Why did I not submit all this as PRs to upstream alot? The main r= easons > > > > > were my lack of time and disagreement with the upstream about pro= ject > > > > > status. From what I can tell, alot maintainers consider the proje= ct to > > > > > be mature, so they prioritize stability and small incremental cha= nges. > > > > > From my perspective, alot is lacking some critical features -- so= me > > > > > implemented in my fork already, some planned -- which makes it > > > > > borderline-unusable for me. As implementing those features requir= ed > > > > > large-scale architectural changes and my free time was quite limi= ted, I > > > > > prioritized quickly implementing the things I cared about over > > > > > progressing in small incremental stable easily-reviewable steps. > > > >=20 > > > > I have a similar impression about the project status. I'm curious: = What > > > > are the architectural changes that you made? > > >=20 > > >=20 > > > Yes, the speed at which alot progresses is borderline problematic. Th= is is of > > > course down to the small number of core contributors and the fact tha= t for all > > > of us life goes on an priorities change. > > >=20 > > > One problem is that the project attracts many users interested in pus= hing what > > > I'd call "hotfixes" to address missing features: Often people would p= resent > > > a (nicely working) proof-of concept that is not well documented, test= ed, and > > > doesn't adhere to common code conventions, only not to follow up on t= heir > > > promises to "clean things up", for all too understandable reasons. > > > Still, I believe that just merging everything will quickly kill the p= roject as > > > a) this leads to code that is very difficult and time-consuming to ma= intain and > > > b) broken features are very damaging to user's perception of the soft= ware, much > > > more so than missing ones. > > >=20 > > > I am not accusing you of anything here, Anton. I just wish to point o= ut > > > potential long term difficulties and clarify that I tried to err on t= he side of > > > cautiousness to keep alot afloat in a usable state for most (potentia= l) users. > >=20 > > 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 >=20 > 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 t= he > 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). >=20 > > (and in fact see many of my changes as > > cleanup and simplification). >=20 > I'm more than happy to push some of them. >=20 > > 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. > >=20 > > 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. >=20 > Yes, I agree. There are many features that I'm personally missing but > either don't yet know how to implement, or already have thought about them > and can see how much extra work it'd be. > I welcome disruption. However, it'd be constructive to introduce changes = one at > a time, discuss, then implement them with all bells and whistles (read: d= ocument). >=20 > > > > > At this point my tree has over 200 new commits and some ~4k chang= ed > > > > > 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. > > > > >=20 > > > > > Any comments or questions are very much welcome. I can also be re= ached > > > > > on IRC as elenril. > > > >=20 > > > > Have you tried raising these concerns with upstream before your for= k? > > > > Have you tried gathering a team around an idea and starting somethi= ng > > > > new together? > > > >=20 > > > > Frankly, upstream is borderline small already, and the way you star= ted > > > > your fork probably will not attract a team of people who want to ma= ke > > > > that new fork their (common) own or are looking for a stronger team. > > >=20 > > > I share Michael's concerns about further splintering the small group = of > > > developers and believe that this would be to the detriment of both pr= ojects. > > >=20 > > > 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 a= nd as > > > a fun distraction. I have tried to squeeze in time to review pull req= uests when > > > possible and am grateful for the many code contributions over the yea= rs, most > > > notably the big steps towards pgp/mime, python3 and notmuch2, all of = which I'd > > > have never found the time to implement myself. > > >=20 > > > It has so far been a successful, albeit slow, strategy to try and coo= rdinate > > > efforts and I would very much like to see this going on, but without > > > sacrificing the quality of the code or the relative mature user exper= ience. > >=20 > > And here is precisely the crux of the problem. My changes are pretty > > drastic and 1) there WILL be bugs 2) someone WILL find them to degrade > > their user experience. You cannot always satisfy everyone. >=20 > I am actually fine with breaking things. > But it has to be justified and changes need to at least be documented som= ewhere. > Users will adjust or move on. But it is difficult to "re-sort" code once = it > becomes inconsistent or unpredictable in my opinion. >=20 >=20 > > Combined with the fact that I also have a lot on my plate and don't see > > myself reshaping my tree into nicely packaged atomic changes with a > > ribbon on top (at least not any time soon). >=20 > That's too bad. Even small PR's would be welcome. >=20 >=20 > > > To be clear: I still do not consider alot "mature" in the sense that = I'd oppose > > > radical refactoring. This is reflected in its version number :) > >=20 > > If you can find the time for it, maybe try to look at the individual > > changes in my tree. Try it out, see what makes sense to you, what > > doesn't, etc. I would be happy to see it all merged into alot, just > > don't see how it can practically be done through the normal channels. >=20 > Look, if you can't be bothered to go via "the normal channels", > then it's unlikely that anyone wants to spend the time to dig though your= code > to find (upstream) usable nuggets. If someone does, and re-packages into = a PR > then cool. I don't see myself spending much time on that I'm afraid. >=20 >=20 > > E.g. one thing I expect to be contentious is the removal of urwidtrees > > use. I understand you are its author, so it may be unpleasant to hear, > > but I found it to be a major obstacle to implementing quote folding. >=20 > No: I authored urwidtrees out of necessity. Urwid simply did not have > a widget for trees at the time and I wanted to replicate the sup/gmail > type of buffer. It is not particularly great code and I'd be happy to see= it go. >=20 > Best wishes, =20 > P --===============6946972824496193216== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable - 
[~] git clone https://git.khirnov.net/alot.git            =20
Cloning into 'alot'...                       =20
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=E2=80=99d be very happy to see these f= eatures in > (mainline) alot! > > I agree that some of alot=E2=80= =99s underlying code is ready for refactoring > and urwid in particular = has been a big drag on quickly implementing things. > Also, I=E2=80=99d = be interested in hearing your thoughts on deprecating some =E2=80=9Cunworth= y=E2=80=9D > features in order to reduce the maintenance effort!

That is largely a matter of perspective and personal preference. E.g. am= ong the things gone in my tree are: - removing messages - I dropped that be= cause I considered that code potentially dangerous, had no use for it mysel= f, and just didn=E2=80=99t 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 imp= lement quote folding, but also made sense to me since I never want to see m= ore than one message at once; again, someone who prefers collapsing message= s 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 k= eep 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 statu= s. From what I can tell, alot maintainers consider the project to be mature= , so they prioritize stability and small incremental changes. From my persp= ective, alot is lacking some critical features =E2=80=93 some implemented i= n my fork already, some planned =E2=80=93 which makes it borderline-unusabl= e for me. As implementing those features required large-scale architectural= changes and my free time was quite limited, I prioritized quickly implemen= ting the things I cared about over progressing in small incremental stable = easily-reviewable steps.

I have a similar impression about the project status. I=E2=80=99m curiou= s: 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 tha= t for all of us life goes on an priorities change.

One problem is that the project attracts many users interested in pushin= g what I=E2=80=99d call =E2=80=9Chotfixes=E2=80=9D to address missing featu= res: Often people would present a (nicely working) proof-of concept that is= not well documented, tested, and doesn=E2=80=99t adhere to common code con= ventions, only not to follow up on their promises to =E2=80=9Cclean things = up=E2=80=9D, 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 feature= s are very damaging to user=E2=80=99s 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 sid= e 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 wo= uld not call my changes =E2=80=9Chotfixes=E2=80=9D, as I tried to keep cont= inuous 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: =E2=80=9Cnot at= all, I=E2=80=99m only sharing my code here=E2=80=9D, then don=E2=80=99t be= surprised if your efforts die the same death and quickly disappear as so m= any other notmuch projects before. If you are fine with that: great. But I = suppose you wouldn=E2=80=99t have shared your code here unless you=E2=80=99= 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=E2=80=99m more than happy to push some of them.

But I did make an explicit decision to prioritise rapidly adding new fun= ctionality, 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 i= t 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.

Yes, I agree. There are many features that I=E2=80=99m personally missin= g but either don=E2=80=99t yet know how to implement, or already have thoug= ht about them and can see how much extra work it=E2=80=99d be. I welcome di= sruption. However, it=E2=80=99d be constructive to introduce changes one at= a time, discuss, then implement them with all bells and whistles (read: do= cument).

At this point my tree has over 200 new commits and some ~4k changed line= s, so it=E2=80=99s looking increasingly unlikely that I=E2=80=99ll ever fin= d the free time and motivation to upstream it =E2=80=93 especially given al= ot=E2=80=99s glacial pace of development recently. If people are interested= in using this, I=E2=80=99ll probably fork it =E2=80=9Cproperly=E2=80=9D un= der a new name.

Any comments or questions are very much welcome. I can also be reached o= n IRC as elenril.

Have you tried raising these concerns with upstream before your fork? Ha= ve you tried gathering a team around an idea and starting something new tog= ether?

Frankly, upstream is borderline small already, and the way you started y= our fork probably will not attract a team of people who want to make that n= ew fork their (common) own or are looking for a stronger team.

I share Michael=E2=80=99s concerns about further splintering the small g= roup of developers and believe that this would be to the detriment of both = projects.

It=E2=80=99s no secret that I am ready to give the helm to others. I hav= e 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 review pull re= quests when possible and am grateful for the many code contributions over t= he years, most notably the big steps towards pgp/mime, python3 and notmuch2= , all of which I=E2=80=99d have never found the time to implement myself.

It has so far been a successful, albeit slow, strategy to try and coordi= nate efforts and I would very much like to see this going on, but without s= acrificing the quality of the code or the relative mature user experience.<= /p>

And here is precisely the crux of the problem. My changes are pretty dra= stic and 1) there WILL be bugs 2) someone WILL find them to degrade their u= ser experience. You cannot always satisfy everyone.

I am actually fine with breaking things. But it has to be justified and = changes need to at least be documented somewhere. Users will adjust or move= on. But it is difficult to =E2=80=9Cre-sort=E2=80=9D code once it becomes = inconsistent or unpredictable in my opinion.

Combined with the fact that I also have a lot on my plate and don=E2=80= =99t see myself reshaping my tree into nicely packaged atomic changes with = a ribbon on top (at least not any time soon).

That=E2=80=99s too bad. Even small PR=E2=80=99s would be welcome.

To be clear: I still do not consider alot =E2=80=9Cmature=E2=80=9D in th= e sense that I=E2=80=99d oppose radical refactoring. This is reflected in i= ts version number :)

If you can find the time for it, maybe try to look at the individual cha= nges in my tree. Try it out, see what makes sense to you, what doesn=E2=80= =99t, etc. I would be happy to see it all merged into alot, just don=E2=80= =99t see how it can practically be done through the normal channels.

Look, if you can=E2=80=99t be bothered to go via =E2=80=9Cthe normal cha= nnels=E2=80=9D, then it=E2=80=99s unlikely that anyone wants to spend the t= ime to dig though your code to find (upstream) usable nuggets. If someone d= oes, and re-packages into a PR then cool. I don=E2=80=99t see myself spendi= ng much time on that I=E2=80=99m afraid.

E.g. one thing I expect to be contentious is the removal of urwidtrees u= se. I understand you are its author, so it may be unpleasant to hear, but I= found it to be a major obstacle to implementing quote folding.

No: I authored urwidtrees out of necessity. Urwid simply did not have a = widget for trees at the time and I wanted to replicate the sup/gmail type o= f buffer. It is not particularly great code and I=E2=80=99d be happy to see= it go.

Best wishes,
P

--===============6946972824496193216==-- --===============0360871726466199874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0360871726466199874==--