bug#17544: 24.3; [PATCH] Improved diff-mode navigation/manipulation

[Dima Kogan]

I'd like to get high-level consensus before making any changes. So ...


Eli Zaretskii <eliz@gnu.org> writes:

> Regardless, the doc string of diff--wrap-hunk-navigation is not
> according to our coding style, so please fix it.

OK.


> Also, I don't quite understand why you need changes like this one:
>
>   -   (diff-hunk-next))))))
>   +   (call-interactively 'diff-hunk-next))))))

It's been quite a while since I wrote this, and looking at it just now I
can't tell why this is necessary. So let's say one can take out this
hunk


> and the whole issue of testing called-interactively-p that goes with
> it.  Can you explain?

I'm guessing the interactivity checking in diff-hunk-next and
diff-hunk-prev was intended to keep scripts working as before. Again, it
has been too long to remember specifically.


Andreas Schwab <schwab@linux-m68k.org> writes:

> On Mai 21 2014, Dima Kogan <lists@dima.secretsauce.net> wrote:
>
>> +(setq diff--hunk-prev-internal (symbol-function 'diff-hunk-prev))
>> +(defun diff-hunk-prev (&optional count)
>
> This will break if diff-mode is reloaded.

Will it? diff-hunk-next and -prev are defined just above in the

    (easy-mmode-define-navigation
     diff-hunk diff-hunk-header-re "hunk" diff-end-of-hunk diff-restrict-view

block. If one reloads diff-mode, wouldn't this
easy-mmode-define-navigation block define the old diff-hunk-prev, which
then gets redefined by the code in the patch? It would be nicer to
define these functions properly the first time instead of (effectively)
advising them. But (easy-mmode-define-navigation) allows arbitrary code
to be called after the template, but I need new stuff BEFORE it. Better
ideas welcome.

dima