Re: your vc-hg.el change

Re: your vc-hg.el change

[Glenn Morris]

Dan Nicolaescu wrote (on Sat, 22 Nov 2008 at 09:52 -0800):

> This change:
> 
> +2008-11-22  Glenn Morris  <rgm@gnu.org>
> +
> +       * vc-hg.el (vc-hg-program): New option.
> +       (vc-hg-state, vc-hg-working-revision, vc-hg-command):
> +       Use vc-hg-program rather than hard-coded "hg".
> 
> Why was it done?  Did any user request it?

Yes.

http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00286.html

>  If not, please undo the change. I've never seen Mercurial used with
> another name. vc-cvs has been in the tree for a long time, and it
> does not do this. I'd rather not introduce useless variables. [by
> now I think I wrote most of vc-hg.el]

Re: your vc-hg.el change

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > Dan Nicolaescu wrote (on Sat, 22 Nov 2008 at 09:52 -0800):
  > 
  > > This change:
  > > 
  > > +2008-11-22  Glenn Morris  <rgm@gnu.org>
  > > +
  > > +       * vc-hg.el (vc-hg-program): New option.
  > > +       (vc-hg-state, vc-hg-working-revision, vc-hg-command):
  > > +       Use vc-hg-program rather than hard-coded "hg".
  > > 
  > > Why was it done?  Did any user request it?
  > 
  > Yes.
  > 
  > http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00286.html

That can be solved the unix way by setting the correct path.  The
mercurial subset used in vc-hg.el is rather small and it's behavior
probably not changed since the beginning.  I am against adding extra
configuration that has no clear benefits, so as the de facto maintainer
of that file I decided to undo the change.  Thanks.

Re: your vc-hg.el change

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>> +2008-11-22  Glenn Morris  <rgm@gnu.org>
>> +
>> +       * vc-hg.el (vc-hg-program): New option.
>> +       (vc-hg-state, vc-hg-working-revision, vc-hg-command):
>> +       Use vc-hg-program rather than hard-coded "hg".
>> 
>> Why was it done?  Did any user request it?
>
> Yes.
>
> http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00286.html

Norman Gray wrote:

> > Within vc-hg.el, the "hg" command is hard-wired as that precise
> > string, rather than being configurable. This is awkward for me at
> > least, since I organise myself so that tools (potentially in
> > multiple different versions) are kept out of /usr/local and similar,
> > and paged in and out via per-shell adjustments to PATH. But that
> > means that hg typically isn't on the default path that emacs picks
> > up.

This exotic setup is probably not a reason to change vc-hg, especially
when there is no equivalent in the other VC backends.  Maybe OP can come
up with a different way to do what he wants (e.g., advising the VC
functions to swap in the correct path).

Re: your vc-hg.el change

[Glenn Morris]

Chong Yidong wrote:

> when there is no equivalent in the other VC backends.

Apart from arch, svn, and bzr.

I really don't see what the big deal is in having a defcustom, and I
think that all the vc backends should be as similar as possible. (I
suspect this means I have condemned those other variables to be
removed.)

Re: your vc-hg.el change

[Glenn Morris]

Dan Nicolaescu wrote:

> configuration that has no clear benefits, so as the de facto maintainer
> of that file I decided to undo the change.  Thanks.

Please list yourself in the file as maintainer, and I'll add it to my
list of things to leave alone. Please also verify my soluion to
bug#1017 is acceptable.

Re: your vc-hg.el change

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>> when there is no equivalent in the other VC backends.
>
> Apart from arch, svn, and bzr.

Aha, I didn't see those.  It's certainly unfortunate that this kind of
discrepancy exists between the various VC backends, and this needs to be
cleaned up.  (A related problem: the different options that provide
diff-switches for the various backends.)

Actually, I thought of one other reason not to hardcode VC commands.
Some distributions are in the habit of providing different versions of
certain programs under different executable names, e.g. Debian provides
gcc-4.1, gcc-4.2, gcc-4.3; "gcc" itself is a symlink to the latest
installed version, but you can use the other executables if you wish.
But I don't think this currently applies to any VC system, as far as I
know (again, I haven't checked for all the different VC systems).

However, this is not an urgent matter, so let's leave matters as they
stand, with the vc-hg change reverted.  We can come back to this after
the release.

Re: your vc-hg.el change

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> as the de facto maintainer of that file

If you wish to maintain the file, please add yourself to the
"Maintainer" field in the vc-hg.el commentary.

Thanks.

Re: your vc-hg.el change

[Glenn Morris]

Chong Yidong wrote:

> (A related problem: the different options that provide diff-switches
> for the various backends.)

Cough, bug #1384, cough. :)

Re: your vc-hg.el change

[Stephen J. Turnbull]

Chong Yidong writes:

 > But I don't think this currently applies to any VC system, as far as I
 > know (again, I haven't checked for all the different VC systems).

I don't know if it (== multiple versions provided by Debian et al)
applies to Darcs or bzr, but both of those have serious cross-version
incompatibilities and "I can't/won't upgrade" is a regular theme on
both lists.  The ability to easily test user-installed versions
provided by the defcustom is very useful to their users.

 > However, this is not an urgent matter

For bzr, it is mildly important *not* to change the status quo.  Emacs
developers especially will be hurt if bzr doesn't allow pointing to a
user-installed bzr, as every recent bzr release has improved
performance.

Re: your vc-hg.el change

[mail]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> For bzr, it is mildly important *not* to change the status quo.  Emacs
> developers especially will be hurt if bzr doesn't allow pointing to a
> user-installed bzr, as every recent bzr release has improved
> performance.
>

Wouldn't the user's PATH point to the bzr they like? I find it unlikely
that they would be able to reasonably use it otherwise...

Re: your vc-hg.el change

[Stephen J. Turnbull]

mail@justinbogner.com writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > > For bzr, it is mildly important *not* to change the status quo.  Emacs
 > > developers especially will be hurt if bzr doesn't allow pointing to a
 > > user-installed bzr, as every recent bzr release has improved
 > > performance.
 > >
 > 
 > Wouldn't the user's PATH point to the bzr they like?

The bzr I like depends on which project I am working on at the
moment.  Ditto the darcs.  That's one reason why I like git best of
all. ;-)

Specifically, since Emacs has not yet implemented bzr, I really don't
give two shakes of a lamb's tail whether I trash my Emacs repo, or
even whether I can access it on any given day.  In the event I write a
patch I'll be doing it against CVS.  So I can update my bzr for Emacs
nightly.  I don't plan to do that for my Mailman repos as they
occasionally contain code that may not exist anywhere else; I stick to
whatever Gentoo considers stable.

 > I find it unlikely that they would be able to reasonably use it
 > otherwise...

It's a bit fragile, but making that variable buffer-local DTRTs.  YMMV.

Re: your vc-hg.el change

[Norman Gray]

Greetings.

This is picking up a thread of 24 November last year[1].  Apologies: I  
missed the thread then and only re-found it in the archive now.

I was the OP for the small patch, which made the vc-hg-program  
configurable in vc-hg.el, rather than being hard-coded.  The decision  
to include or reject the patch is not mine, and I don't want to re- 
start a discussion, but I'd like to log the context I should have  
added at the time of the thread, for the record.

   * I'm using emacs on OS X here (specifically Aquamacs).  There,  
applications start as children of a daemon which is not a child of the  
login process, so adjusting the path that they see is slightly  
intricate, rather than being simply an adjustment to .bashrc (it  
implies configuration in two places rather than one, which is always  
bad).

   * On this platform, applications are installed in standalone  
directories per-application/version, rather than simply dropped into / 
usr/local.  Thus having a per-application install of hg is arguably  
DTRT on this platform (though this convention is weak for non-GUI  
programs).

Adding this one bit of configuration therefore has clear benefits on  
this platform.

Best wishes,

Norman


[1] http://lists.gnu.org/archive/html/emacs-devel/2008-11/msg00838.html

-- 
Norman Gray  :  http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester

Re: your vc-hg.el change

[Stefan Monnier]

> I was the OP for the small patch, which made the vc-hg-program configurable
> in vc-hg.el, rather than being hard-coded.

I can't figure out why I was so hard-headed last time.  I just added
this variable into the emacs-23 branch.  Not sure if it's exactly the
same patch as yours, since I couldn't get the relevant thread at the
time, but it should be functionally identical (and probably very
similar since there aren't 50 ways to do it).


        Stefan