bug#63470: [PATCH] Use faster option for running vc-hg status

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 63470@debbugs.gnu.org
> Date: Fri, 12 May 2023 15:57:41 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > I don't understand: what will happen to users of Mercurial < 4.2?
> 
> They will get an error message and the vc-dir buffer will fail to
> update.

That's unacceptable, sorry.  There are better solutions than just stop
supporting those users, so this is too harsh.

> > And why cannot we detect the version and dispatch on that, instead of
> > doing this unconditionally?
> 
> hg --version takes a quarter of a second on my machine, which itself
> wipes out a lot of the performance benefit.  We could cache it, but it's
> not clear to me how to do that correctly: there could be different hg
> binaries in different directories, or over TRAMP, or other such things.

There's no reason to assume there's more than one Mercurial
installation on PATH.  We could allow reinitialization of the version,
but that would be holier that Pope, IMO.  We don't do that with Git,
AFAIR.

> I could add a user option to revert to the old behavior, if you want.

The result of the version test could set the value of the defacustom,
but if we add such a defcustom, its default value should be to probe
the system, not to assume version 4.2 or later.

> (It would be nice if vc was available on ELPA, then maybe we could just
> tell users of old mercurial versions to downgrade to an old version...)

Does package.el support downgrading of packages, let alone of built-in
packages?