[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17544: 24.3; [PATCH] Improved diff-mode navigation/manipulation
From: |
npostavs |
Subject: |
bug#17544: 24.3; [PATCH] Improved diff-mode navigation/manipulation |
Date: |
Sat, 22 Oct 2016 22:49:21 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Dima Kogan <dima@secretsauce.net> writes:
> npostavs@users.sourceforge.net writes:
>
>> Dima Kogan <dima@secretsauce.net> writes:
>>
>>> Here's yet another revised patch. The (call-interactively) at the end of
>>> (diff-apply-hunk) was important, it turns out. This would force it to
>>> use the new logic to move to the next hunk, instead of the legacy logic.
>>> I purposely left the behavior of (diff-next-hunk) unchanged from before
>>> when running non-interactively, and here I explicitly want the new
>>> behavior.
>>
>> If both behaviours are needed, it would be much better if lisp code
>> could choose between them without having to use call-interactively,
>> that's quite an awkward interface.
>
> Hi. I'm open to suggestions. The goal was to retain the previous logic
> for any existing code, but to provide improved user-facing behavior.
> Given this, it doesn't seem to me to be too awkward to pass-on the
> "interactive-p" state to child functions.
>
But you're synthesizing interactiveness in diff-apply-hunk, so it looks
like interactiveness is not what you actually care about. You could do
something like this instead:
(defun diff-hunk-next (&optional count skip-hunk-start)
"Go to the next COUNT'th hunk"
(interactive (list (prefix-numeric-value current-prefix-arg) t))
(diff--wrap-navigation
skip-hunk-start
"next hunk"
'diff--internal-hunk-next
diff-hunk-header-re
(lambda () (goto-char (car (diff-bounds-of-hunk))))
count))
Then instead of (call-interactively 'diff-hunk-next) you can just do
(diff-hunk-next nil t)
> Am I wrong to want to preserve
> existing behavior for elisp code? If so, then the entire old path can
> simply go away unconditionally.
Maybe. What about the other calls to diff-hunk-next? Was there a
reason you kept them the same?