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 10063 invoked from network); 20 Jun 2020 10:44:08 -0000
Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2)
  by inbox.vuxu.org with ESMTPUTF8; 20 Jun 2020 10:44:08 -0000
Received: (qmail 14479 invoked by alias); 20 Jun 2020 10:43:58 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
List-Unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
Sender: zsh-workers@zsh.org
X-Seq: 46084
Received: (qmail 16024 invoked by uid 1010); 20 Jun 2020 10:43:58 -0000
X-Qmail-Scanner-Diagnostics: from out4-smtp.messagingengine.com by f.primenet.com.au (envelope-from <d.s@daniel.shahaf.name>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.102.3/25842. spamassassin: 3.4.4.  
 Clear:RC:0(66.111.4.28):SA:0(-2.6/5.0):. 
 Processed in 3.643755 secs); 20 Jun 2020 10:43:58 -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: <xms:SejtXkFo1l2JnN0GANhlwPx4vubH4kvlIksBybXlcXMzFblJTvu3qw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejkedgfeduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh
    dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi
    vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeektdefleegvefhue
    efteeifeevudekgfehgeevfeduffetledvtedvffdvueekudenucffohhmrghinhepmhgv
    rhgtuhhrihgrlhdqshgtmhdrohhrghenucfkphepjeelrddujeeirdefledrieelnecuve
    hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggr
    nhhivghlrdhshhgrhhgrfhdrnhgrmhgv
X-ME-Proxy: <xmx:SejtXtXl1lcYDvjMoQWi3uhAF8xLBJWOtDez3LqLNEMsUOLFaOR2Ow>
    <xmx:SejtXuKRuQbfJN43CLmxiFQYyNFY6nFGITop2nnJ9T-MXNDpeHMUOA>
    <xmx:SejtXmGVT1NY-cvwqm0b3jKgEfPZ4Md91QSx6gIBNcsYriC-DCFrVw>
    <xmx:SejtXjWVkN-HCVPgtjTuQ_w7YZD8MIQ4vzEjDanGB9sYQy6B_xaEjg>
Date: Sat, 20 Jun 2020 10:43:17 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Manuel Jacob <me@manueljacob.de>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH v3] Add code to Mercurial VCS backend to show topic if
 there is any.
Message-ID: <20200620104317.51bac64a@tarpaulin.shahaf.local2>
In-Reply-To: <20200619233112.191102-1-me@manueljacob.de>
References: <20200619233112.191102-1-me@manueljacob.de>
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 Sat, 20 Jun 2020 01:31 +0200:
> "Topics" is an experimental concept in Mercurial that augments the
> current branching concept (called "named branches").
>=20
> For more information, see the not always up-to-date Mercurial Wiki page
> https://www.mercurial-scm.org/wiki/TopicPlan.
> ---
>  Functions/VCS_Info/Backends/VCS_INFO_get_data_hg | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>=20
> diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg b/Functions=
/VCS_Info/Backends/VCS_INFO_get_data_hg
> index cd5ef321d..deeb331a0 100644
> --- a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
> +++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
> @@ -5,7 +5,7 @@
> =20
>  setopt localoptions extendedglob NO_shwordsplit
> =20
> -local hgbase bmfile branchfile rebasefile dirstatefile mqseriesfile \
> +local hgbase bmfile branchfile topicfile rebasefile dirstatefile mqserie=
sfile \
>      curbmfile curbm \
>      mqstatusfile mqguardsfile patchdir mergedir \
>      r_csetid r_lrev r_branch i_bmhash i_bmname \
> @@ -27,6 +27,7 @@ mergedir=3D"${hgbase}/.hg/merge/"
>  bmfile=3D"${hgbase}/.hg/bookmarks"
>  curbmfile=3D"${hgbase}/.hg/bookmarks.current"
>  branchfile=3D"${hgbase}/.hg/branch"
> +topicfile=3D"${hgbase}/.hg/topic"
>  rebasefile=3D"${hgbase}/.hg/rebasestate"
>  dirstatefile=3D"${hgbase}/.hg/dirstate"
>  mqstatusfile=3D"${patchdir}/status" # currently applied patches
> @@ -69,6 +70,13 @@ fi
>  # If we still don't know the branch it's safe to assume default
>  [[ -n ${r_branch} ]] || r_branch=3D"default"
> =20
> +# Show topic if there is any (the UI for this experimental concept is no=
t yet
> +# final, but for a long time the convention has been to join the branch =
name
> +# and the topic name by a colon)
> +if [[ -f ${topicfile} && -r ${topicfile} && -s ${topicfile} ]] ; then
> +    r_branch=3D${r_branch}:$(head -n 1 ${topicfile})
> +fi

I'm happy to read the file directly, despite experimentality, given the
discussion elsethread that you'll propose a corresponding unit test to
the upstream maintainers.

Using $(head) forks, and we try to avoid forks because they're expensive
on some platforms.  In this case, you could use =C2=ABIFS=3D read -r REPLY
<$topicfile=C2=BB instead.  (The construct =C2=AB$(<foo)=C2=BB, just above =
the hunk
context, is special-cased to not fork.)

As written, existing set-branch-format hooks would see the ${hook_com[branc=
h]}
input argument set to strings such as "default:mytopic".  Would this
behaviour be expected, or would people rather expect ${hook_com[branch]}
to be set to strings such as "default" even when .hg/topic exists, and
to have a new ${hook_com[foo]} key whose value would be "mytopic" (or
possibly "default:mytopic")?  This would affect the API to hooks but
would not affect the final output.

Speaking of which, have you tested the output with the get-revision
style set?  (Run =C2=ABzstyle ':vcs_info:hg:*' get-revision true=C2=BB
interactively or in your zshrc.)  As written, I expect this patch would
result in output such as =C2=ABdefault:mytopic:c04503e1dba4:0=C2=BB with th=
e style
set, compared to =C2=ABdefault:c04503e1dba4:0=C2=BB with the style set in c=
urrent
master.  I don't see a problem here; just raising the point for
awareness.

(The latter output can be customised by setting the the hgrevformat and
branchformat styles with the 'zstyle' builtin.  In the examplar output
above, "c04503e1dba4" is %r in hgrevformat; the final=C2=A0"0" is %h in
hgrevformat; "c04503e1dba4:0", as an atomic unit, is %r in branchformat;
and "default"/"default:mytopic" is %b in branchformat.  The whole
shebang is then %b in the formats/actionformats styles.)

Similarly, as written, the %b expando in "formats", "actionformats", and
"branchformat" will always be replaced with a string such as
"default:mytopic".  If someone wants to change the format,=C2=B9 they won't
be able to achieve that using zstyle settings alone; they'd have to
write an appropriate vcs_info hook in their zshrc.  What do you think
of, say, making the topic name available as a separate expando in
branchformat?  Again, this would not affect the default output, but make
customizations easier to implement.

=C2=B9 Use-cases for changing the format include: colouring "default" and
"mytopic" differently (compare =C2=ABzstyle '*' branchformat '%B%b%%b %U%r%=
u'=C2=BB
when the get-revision style is set); changing the colon to a space for
readability or copypasteability; and perhaps even eliding the topic
name entirely(?).

>  # The working dir has uncommitted-changes if the revision ends with a +
>  if [[ $r_lrev[-1] =3D=3D + ]] ; then
>      hgchanges=3D1

Cheers,

Daniel