[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14443: 24.3.50; log-view-diff and log-view-diff-changeset broken in

From: Dmitry Gutov
Subject: 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)
Date: Thu, 23 May 2013 23:53:52 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

On 23.05.2013 20:52, Eli Zaretskii wrote:
Date: Thu, 23 May 2013 20:46:07 +0400
From: Dmitry Gutov <address@hidden>
CC: address@hidden, Eli Zaretskii <address@hidden>

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

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]