[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#927: vc-bzr.el with cygwin bzr
From: |
Phillip Lord |
Subject: |
bug#927: vc-bzr.el with cygwin bzr |
Date: |
Tue, 09 Sep 2008 16:44:11 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (windows-nt) |
>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> My hack is platform specific. A better solution would be, to modify
>> vc-bzr-command to be either of the form "bzr-program-name" or
>> '("python name" "bzr name"). vc-bzr-command would need to be
>> modified to cope. There is couple of other places vc-bzr-command is
>> used which would need changing also.
Stefan> A better solution would be to write a w32 wrapper for Bzr (an
Stefan> plain w32 executable that runs python with the bzr script), so
Stefan> that it does not rely on cygwin's own handling of #!
I don't think that the two contradict. Both would be possible. But, yes,
a bzr.bat in cygwin would probably solve the problem.
Stefan> After all, does Cygwin's bzr work with any other program
Stefan> that's not part of Cygwin? I'd guess not, which is why I think
Stefan> the problem is not specific to Emacs.
This depends on how they launch bzr; for vc-bzr, for instance, if vc
used an external shell-command instead of start-process it would work.
Even if emacs was using dos as it's shell, I could reconfigure
bzr-command to be "c:/cygwin/bin/python bzr"; unfortunately, you can't
do this with start-process because the space is interpreted as part of
the command name, and bzr not considered an argument.
Given that the change I suggested is quite small, is there a problem
with putting it in; I'm willing to send in a patch if you wish. It would
also support the use case where one the user wishes to use a specific
python to run bzr. It should be transparent to other users.
In the meantime, if I can work out how to do it, I'll write to the
cygwin packager and ask for a bzr.bat to be added to cygwin (having
tested that it works). As you say, it would help to make it more
usuable, irrespective of emacs.
Phil