[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17544: 24.3; [PATCH] Improved diff-mode navigation/manipulation
From: |
Dima Kogan |
Subject: |
bug#17544: 24.3; [PATCH] Improved diff-mode navigation/manipulation |
Date: |
Sat, 03 Sep 2016 14:24:20 -0700 |
User-agent: |
mu4e 0.9.17; emacs 25.1.1 |
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