Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

bug#14443: 24.3.50; log-view-diff and log-view-diff-changeset broken in vc-bzr-change-log-mode and vc-annotate-mode (on w32)

1 view
Skip to first unread message

Dmitry Gutov

unread,
May 22, 2013, 6:22:23 PM5/22/13
to 14...@debbugs.gnu.org

1. find-file //lisp/progmodes/ruby-mode.el

2. Press C-x v L, C-x v l or C-x v g.

3. Pick a revision, press d or D.

4. See something like either of the following:

=== modified file 'lisp/progmodes/ruby-mode.el'
bzr: ERROR: [Error 2] The system cannot find the file specified

=== modified file 'lisp/ChangeLog'
bzr: ERROR: [Error 2] The system cannot find the file specified


In GNU Emacs 24.3.50.4 (i686-pc-mingw32)
of 2013-05-23 on SOL
Bzr revision: 112672 mon...@iro.umontreal.ca-20130522213500-10ibn1m9ze3b0pgc
Windowing system distributor `Microsoft Corp.', version 6.1.7601



Glenn Morris

unread,
May 23, 2013, 3:25:29 AM5/23/13
to Dmitry Gutov, 14...@debbugs.gnu.org
Dmitry Gutov wrote:

> 1. find-file //lisp/progmodes/ruby-mode.el
>
> 2. Press C-x v L, C-x v l or C-x v g.
>
> 3. Pick a revision, press d or D.
>
> 4. See something like either of the following:
>
> === modified file 'lisp/progmodes/ruby-mode.el'
> bzr: ERROR: [Error 2] The system cannot find the file specified

Works fine on GNU/Linux.
Does '//' (in step 1) mean something special on MS Windows?



Dmitry Gutov

unread,
May 23, 2013, 8:09:15 AM5/23/13
to Glenn Morris, 14...@debbugs.gnu.org
On 23.05.2013 11:25, Glenn Morris wrote:
> Dmitry Gutov wrote:
>
>> 1. find-file //lisp/progmodes/ruby-mode.el
>>
>> 2. Press C-x v L, C-x v l or C-x v g.
>>
>> 3. Pick a revision, press d or D.
>>
>> 4. See something like either of the following:
>>
>> === modified file 'lisp/progmodes/ruby-mode.el'
>> bzr: ERROR: [Error 2] The system cannot find the file specified
>
> Works fine on GNU/Linux.

Yes, sorry, next time instead of "on w32" I'll write "w32-only".
I usually test these kind of bugs in both.

> Does '//' (in step 1) mean something special on MS Windows?

Nope, just an abbreviation.



Glenn Morris

unread,
May 23, 2013, 12:09:40 PM5/23/13
to Dmitry Gutov, 14...@debbugs.gnu.org

Can you edebug it and find out exactly what filename is passed to the OS?
Presumably it doesn't like it for some reason.



Eli Zaretskii

unread,
May 23, 2013, 12:23:04 PM5/23/13
to Glenn Morris, 14...@debbugs.gnu.org, dgu...@yandex.ru
> From: Glenn Morris <r...@gnu.org>
> Date: Thu, 23 May 2013 03:25:29 -0400
> Cc: 14...@debbugs.gnu.org
>
> Dmitry Gutov wrote:
>
> > 1. find-file //lisp/progmodes/ruby-mode.el
> >
> > 2. Press C-x v L, C-x v l or C-x v g.
> >
> > 3. Pick a revision, press d or D.
> >
> > 4. See something like either of the following:
> >
> > === modified file 'lisp/progmodes/ruby-mode.el'
> > bzr: ERROR: [Error 2] The system cannot find the file specified
>
> Works fine on GNU/Linux.

Works fine for me on w32 as well.

Dmitry, you will have to dig deeper. E.g., what command is sent down
to bzr in this case and barfs?



Dmitry Gutov

unread,
May 23, 2013, 12:46:07 PM5/23/13
to Glenn Morris, 14...@debbugs.gnu.org
On 23.05.2013 20:09, Glenn Morris wrote:
>
> Can you edebug it and find out exactly what filename is passed to the OS?
> Presumably it doesn't like it for some reason.

vc-bzr.el uses lexical-binding, so `edebug-eval-expression' doesn't
help. Putting a `message' call in `vc-bzr-diff' yields this:

files: (~/vc/emacs-bzr/trunk/) buffer: *vc-diff* rev1: 112671 rev2: 112672

> Dmitry, you will have to dig deeper. E.g., what command is sent down
> to bzr in this case and barfs?

I'm not sure how to find out. `vc-do-command' receives the following
arguments:

buffer: *vc-diff* command: bzr file-or-list: nil flags: (diff
--diff-options -u -r 112671..112672)

By the way, here's a (somewhat related) command that fails when invoked
from command line:

bzr diff --diff-options -U0

(`bzr diff' works fine.)

Does Bazaar require additional programs to be installed? After recent
overhaul of my MinGW installation, a number of Unix utilities became
unavailable globally, including `diff'.



Eli Zaretskii

unread,
May 23, 2013, 12:52:10 PM5/23/13
to Dmitry Gutov, 14...@debbugs.gnu.org
> Date: Thu, 23 May 2013 20:46:07 +0400
> From: Dmitry Gutov <dgu...@yandex.ru>
> CC: 14...@debbugs.gnu.org, Eli Zaretskii <el...@gnu.org>
>
> I'm not sure how to find out.

You could put a breakpoint on call-process and examine its arguments,
for example.

> `vc-do-command' receives the following arguments:
>
> buffer: *vc-diff* command: bzr file-or-list: nil flags: (diff
> --diff-options -u -r 112671..112672)

Why do you use --diff-options? "bzr diff" works as if -u was
specified anyway, and will use its internal emulation of Diff if you
don't pass --diff-options.

> By the way, here's a (somewhat related) command that fails when invoked
> from command line:
>
> bzr diff --diff-options -U0
>
> (`bzr diff' works fine.)
>
> Does Bazaar require additional programs to be installed?

Only if you use --diff-options.

> After recent overhaul of my MinGW installation, a number of Unix
> utilities became unavailable globally, including `diff'.

That's probably related. So restore your diff.exe, and things will
work again. They do for me, because my diff.exe is in perfect working
order.



Glenn Morris

unread,
May 23, 2013, 12:59:05 PM5/23/13
to Dmitry Gutov, 14...@debbugs.gnu.org
Dmitry Gutov wrote:

> bzr diff --diff-options -U0
>
> (`bzr diff' works fine.)
>
> Does Bazaar require additional programs to be installed?

bzr help diff:

--diff-options=ARG Pass these options to the external diff program.

So, don't specify --diff-options if you don't have a working "diff"
executable.



Dmitry Gutov

unread,
May 23, 2013, 3:53:52 PM5/23/13
to Eli Zaretskii, 14...@debbugs.gnu.org
On 23.05.2013 20:52, Eli Zaretskii wrote:
>> Date: Thu, 23 May 2013 20:46:07 +0400
>> From: Dmitry Gutov <dgu...@yandex.ru>
>> CC: 14...@debbugs.gnu.org, Eli Zaretskii <el...@gnu.org>
>>
>> I'm not sure how to find out.
>
> You could put a breakpoint on call-process and examine its arguments,
> for example.

I've rummaged around the manual a bit, and still don't understand what
the recommended workflow is.

Should I normally do `edebug-defun' before adding a breakpoint?

How do I display the value of a local variable? Even after breakpoint
hits, using `edebug-eval-expression' with the variable name still gives
me "variable is void".

How do I un-instrument a function? AFAICS, there are no commands like
`edebug-cancel-', `-reset-' or `-remove-'.

Please point me at any relevant documentation.

>> `vc-do-command' receives the following arguments:
>>
>> buffer: *vc-diff* command: bzr file-or-list: nil flags: (diff
>> --diff-options -u -r 112671..112672)
>
> Why do you use --diff-options? "bzr diff" works as if -u was
> specified anyway, and will use its internal emulation of Diff if you
> don't pass --diff-options.

`vc-bzr-diff' does that automatically because `diff-switches' is '-u' here.

If I remove that explicit setting from my config, it falls back to "-c",
and that (when external diff program is present, of course) makes vc-bzr
produce context diffs.
Curiously, vc-git still uses the unified format in that case.

Setting it to nil works as you expected.

>> After recent overhaul of my MinGW installation, a number of Unix
>> utilities became unavailable globally, including `diff'.
>
> That's probably related. So restore your diff.exe, and things will
> work again. They do for me, because my diff.exe is in perfect working
> order.

I've done that, works fine now. Sorry for the false alarm, I should have
investigated it more myself first.

Using diff.exe from the GnuWin32 collection is recommended, right?



Eli Zaretskii

unread,
May 23, 2013, 4:17:27 PM5/23/13
to Dmitry Gutov, 14...@debbugs.gnu.org
> Date: Thu, 23 May 2013 23:53:52 +0400
> From: Dmitry Gutov <dgu...@yandex.ru>
> CC: r...@gnu.org, 14...@debbugs.gnu.org
>
> On 23.05.2013 20:52, Eli Zaretskii wrote:
> >> Date: Thu, 23 May 2013 20:46:07 +0400
> >> From: Dmitry Gutov <dgu...@yandex.ru>
> >> CC: 14...@debbugs.gnu.org, Eli Zaretskii <el...@gnu.org>
> >>
> >> I'm not sure how to find out.
> >
> > You could put a breakpoint on call-process and examine its arguments,
> > for example.
>
> I've rummaged around the manual a bit, and still don't understand what
> the recommended workflow is.
>
> Should I normally do `edebug-defun' before adding a breakpoint?

Actually, I meant GDB on the C level, but since you asked...

Yes, at least that's what I do.

> How do I display the value of a local variable?

C-x C-e with point after it, I guess. I'm quite sure it worked for me
when I used that last.

> How do I un-instrument a function? AFAICS, there are no commands like
> `edebug-cancel-', `-reset-' or `-remove-'.

Reload the .el file.

> Using diff.exe from the GnuWin32 collection is recommended, right?

That's what I use, yes.



Dmitry Gutov

unread,
May 23, 2013, 4:25:39 PM5/23/13
to Eli Zaretskii, 14...@debbugs.gnu.org
On 24.05.2013 0:17, Eli Zaretskii wrote:
>>> You could put a breakpoint on call-process and examine its arguments,
>>> for example.
>>
>> I've rummaged around the manual a bit, and still don't understand what
>> the recommended workflow is.
>>
>> Should I normally do `edebug-defun' before adding a breakpoint?
>
> Actually, I meant GDB on the C level, but since you asked...

Oh. Though I believe it's called something like `Fcall_process' there.

>> How do I display the value of a local variable?
>
> C-x C-e with point after it, I guess. I'm quite sure it worked for me
> when I used that last.

Then I guess you've used it in a buffer without lexical-binding.

>> How do I un-instrument a function? AFAICS, there are no commands like
>> `edebug-cancel-', `-reset-' or `-remove-'.
>
> Reload the .el file.

Thanks! It's kind of an obvious solution, but I could've spent quite a
while looking for a specialized command.



0 new messages