From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18752 invoked from network); 19 Jun 2020 10:08:25 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 19 Jun 2020 10:08:25 -0000 Received: (qmail 190 invoked by alias); 19 Jun 2020 10:08:15 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: Sender: zsh-workers@zsh.org X-Seq: 46076 Received: (qmail 17669 invoked by uid 1010); 19 Jun 2020 10:08:15 -0000 X-Qmail-Scanner-Diagnostics: from out5-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25842. spamassassin: 3.4.4. Clear:RC:0(66.111.4.29):SA:0(-2.6/5.0):. Processed in 4.232981 secs); 19 Jun 2020 10:08:15 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejiedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeektdefleegvefhue efteeifeevudekgfehgeevfeduffetledvtedvffdvueekudenucffohhmrghinhepmhgv rhgtuhhrihgrlhdqshgtmhdrohhrghenucfkphepjeelrddujeeirdefledrieelnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Fri, 19 Jun 2020 10:07:31 +0000 From: Daniel Shahaf To: Manuel Jacob Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Add code to Mercurial VCS backend to show topic if there is any. Message-ID: <20200619100731.099deac3@tarpaulin.shahaf.local2> In-Reply-To: References: <20200607074445.7723-1-me@manueljacob.de> <20200607121443.7c58ee16@tarpaulin.shahaf.local2> <20200608053140.33e79354@tarpaulin.shahaf.local2> <538786d4a3afe4b9432a1469ebafcad8@manueljacob.de> <20200609223416.59a43074@tarpaulin.shahaf.local2> <20200617082743.12b5d092@tarpaulin.shahaf.local2> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Manuel Jacob wrote on Fri, 19 Jun 2020 04:06 +0200: > On 2020-06-17 10:27, Daniel Shahaf wrote: > > Daniel Shahaf wrote on Tue, 09 Jun 2020 22:34 +0000: > >> Manuel Jacob wrote on Tue, 09 Jun 2020 03:15 +0200: > >> > On 2020-06-08 07:31, Daniel Shahaf wrote: > >> > > Manuel Jacob wrote on Sun, 07 Jun 2020 15:31 +0200: > >> > >> Hi Daniel, > >> > >> > >> > >> On 2020-06-07 14:14, Daniel Shahaf wrote: > >> > >> > Manuel Jacob wrote on Sun, 07 Jun 2020 09:44 +0200: > >> > >> >> "Topics" is an experimental concept in Mercurial that augments= the > >> > >> >> current branching concept (called "named branches"). > >> > >> >> > >> > >> >> For more information, see the not always up-to-date Mercurial = Wiki > >> > >> >> page > >> > >> >> https://www.mercurial-scm.org/wiki/TopicPlan. > >> > >> > > >> > >> > I assume "experimental" means "future releases of Mercurial are= not > >> > >> > promised to be backwards compatible with the current design". > >> > >> > >> > >> It is not yet part of Mercurial itself, but developed separately = as an > >> > >> extension under the Mercurial project roof. > >> > >> > >> > > > >> > > Thanks for the info. In practice, though, it doesn't make that mu= ch > >> > > difference to vcs_info whether the functionality lives in Mercurial > >> > > core > >> > > or in an extension developed by the same development team. I was = more > >> > > concerned with whether the current on-disk data format is promised= to > >> > > be > >> > > supported by future releases of the functionality [whether those b= e in > >> > > hg core or in extensions]. > >> > > > >> > >> > Is the .hg/topic file name and data format set in stone yet? > >> > >> > > >> > >> > What if zsh 5.9 is released and then the Mercurial developers c= hange > >> > >> > the design to make .hg/topic a directory, and release _that_? = Then > >> > >> > everyone who uses zsh 5.9 with hg will be stuck with vcs_info e= rrors > >> > >> > until their distro upgrades to newer zsh. > >> > >> > >> > >> The .hg/topic file works very similar to the .hg/branch file (whi= ch is > >> > >> stable since 2007 and which zsh currently depends on). I can't th= ink > >> > >> of > >> > >> any reason why someone would consider changing the format. > >> > >> > >> > > > >> > > I'm not going to second-guess your assessment, but I am surprised = by > >> > > it. > >> > > >> > The main developer of the topic extension said that there will be cl= ear > >> > message if it changed. When I asked him "do you think it is safe for= a > >> > shell prompt hook to depend on the .hg/topic file name and data > >> > format?", the answer was "safe enough". What he considers "safe enou= gh" > >> > might not be "safe enough" for zsh. > >>=20 > >> Thanks for going to the horse's mouth. Yes, "safe enough" is a bit > >> vague. > >>=20 > >> > As a zsh user, I find it reassuring that the standards for inclusion= are high. > >>=20 > >> Thanks for your understanding and for making it explicit =E2=98=BA > >>=20 > >> > >> The file would only be created if a user installs and activates t= he > >> > >> extension, and explictly creates a topic (a specific kind of feat= ure > >> > >> branch), so that makes it even more unlikely that something break= s. > >> > > > >> > > I do see that if topics are not popular, then the probability that > >> > > a random hg user would be affected by a forward incompatible assum= ption > >> > > in vcs_info is low. However, users of hg topics that uses vcs_info > >> > > _would_ be affected and would have no easy workaround. > >> > > > >> > > Furthermore, it is zsh, not hg, who would receive the consequent b= ug > >> > > reports and negative word-of-mouth. > >> > > > >> > > Could you comment on what options are there to design forward > >> > > compatibility into the patch? It would be good to lay out > >> > > alternatives, > >> > > even if we don't end up implementing any of them. > >> > > >> > One option is that people would have to opt-in to get the topic show= n. > >> > This way, people could be made aware that they=E2=80=99re using some= thing that > >> > could break in the future. However, I don=E2=80=99t know whether zsh= provides a > >> > framework for having this kind of configuration. > >> > > >>=20 > >> Configurability could be provided via the 'zstyle' builtin. Briefly, > >> zstyles map strings ("contexts") to key-to-list-of-words maps by > >> specifying pattern that contexts are matched against. (See the manual > >> for details.) A user might do in their zshrc > >> . > >> zstyle ':vcs_info:hg:*' experimental-features topic > >> . > >> and then the vcs_info backend would run =C2=ABzstyle -a=C2=BB and get = an array > >> =C2=ABreply=3D( topic )=C2=BB. Without that zshrc setting, the array = would be > >> empty. > >>=20 > >> There should be plenty of examples of this in vcs_info, and more in=20 > >> the > >> completion system. >=20 > Do you think an explicit opt-in is necessary in combination with the=20 > other forward-compatibility options? Not necessarily. For example, if hg upstream accepts a unit test for the kind of parsing vcs_info does, I'd consider that reason enough to dispense with the opt-in. Alternatively, if there is a way to probe hg(1)'s output and/or the .hg dir to see what version of the topic extension data format is used, and if we can rely on that version number to be bumped if an incompatible change are made, that too will remove the need for an opt-in. The idea, in any case, is to be as forward compatible with future hg as practicable. > I=E2=80=99m concerned that most people won=E2=80=99t use the feature beca= use they=E2=80=99re > not aware that it exists. Fair point. Let's first see if we can enable the feature without user interaction at all. If that doesn't pan out, then we can see about addressing the lack of awareness. > >> > The hook could check harder that the .hg/topic file is in the expect= ed > >> > format, e.g. checking that it is a regular file. As long as it=E2=80= =99s a > >> > regular file, I=E2=80=99d consider it a gross violation of the user = expectation > >> > if the file contained anything other than simply the topic name. > >> > > >>=20 > >> Makes sense. This way, if there _is_ an upstream=20 > >> backwards-incompatible > >> change [which is fine, of course, in an experimental feature], the > >> fallout would be minimal. > >>=20 > >> Or maybe vcs_info could read just the first line of the file. This > >> way, if future hg adds more info in subsequent lines, we'll be forward > >> compatible with that. >=20 > Good idea. I=E2=80=99ll implement that. Looking forward to the revised patch, then. > >> > I could submit the diff of this patch for inclusion in the "contrib" > >> > directory of the topic extension repository to remind them that peop= le > >> > depend on the file name and data format. > >>=20 > >> Making upstream aware that it has downstreams that depend on the data > >> format would definitely be a Good Thing. A contrib patch wouldn't=20 > >> have > >> been my first choice, though: I'd rather recommend creating a unit=20 > >> test > >> that creates and reads a topic in the same way vcs_info will, with > >> a comment explaining that (and a comment in vcs_info that points to=20 > >> the > >> test). >=20 > Indeed that sounds better than a patch in contrib. There=E2=80=99s curren= tly an=20 > unrelated large patch in-review for the repository the test would be=20 > added to. Not sure whether I can sneak it through on the side. I won=E2= =80=99t=20 > block the zsh patch on that. +1 > >> Or perhaps the vcs_info hg backend should be maintained as part of hg? > >> That would require vcs_info to provide a public API for third-party > >> backends. >=20 > I=E2=80=99m lacking the experience to change vcs_info to provide such pub= lic=20 > API. I wouldn't have expected you to make such a change as part of this patch submission; I was merely brainstorming potential larger-scale changes for the future. To block the patch pending such changes would be to let the perfect be the enemy of the good. > The backend would be part of hg, while the code for writing the topic to= =20 > the file is in another repository. Therefore, the backend itself would=20 > need to provide additional hooks the topic extension could use. Sounds like we should keep vcs_info's design as-is, then. Bugfixes that require concerted changes across three repositories are an imperial pain. > >> Cheers! > >>=20 > >> Daniel >=20 > Thank you for the superb review experience so far! You're welcome, and thanks for taking the forward compatibility concerns in stride! Cheers, Daniel P.S. Unrelated question: Where would you expect the existence of a custom syntax highlighting file for the manual's yodl (*.yo) sources to be documented? We have such a file (Util/zyodl.vim), but I just realized that I forgot to document its existence.