bug#25105: 26.0.50; diff navigation is broken

[Mark Oteiza <mvoteiza@udel.edu>]

Dima Kogan <dima@secretsauce.net> writes:

> Mark Oteiza <mvoteiza@udel.edu> writes:
>> I fail to see how fixing corner cases in diff-apply-hunk has anything
>> to do with diff-{file,hunk}-{next-prev}
>
> The issues being fixed are making anything that operates on hunks more
> consistent, so diff-{file,hunk}-{next-prev} are relevant.

and this entire thread is about the contention over changes specifically
done to diff-{file,hunk}-{next-prev}.

To quote myself: "Fixing C-c C-a to DTRT is great, thanks, but I don't
think the off-by-one navigation changes to "n" and "p" (diff-hunk-next,
diff-hunk-prev) make sense."
https://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00222.html

>> At first glance, it looks like the following patch would restore the
>> previous behavior, however it completely breaks auto refinement.
>>
>> <snip>
>
> If you want to restore the previous behavior, wouldn't a revert be
> better? Or are you trying to restore only a subset of the previous
> behavior?

I did not submit it as a solution to the problem at hand.  The fact that
the patch breaks auto-refinement means that I cannot define my own
commands to call (diff-{file-hunk}-{prev-next} ARG nil) and have it
work.

Put another way, your changes make it nigh impossible to get the
previous n,p,{,} back without breaking something.

>> With the number of actual bugs (email/format-patch/pre-diff content,
>> and auto refinement) the initial patch caused, perhaps this is best.
>
> The email/format-patch issue has nothing to do with me; it has been a
> problem for years.

Yes it did, as the second recipe in this bug and 6b6abe0d clearly show.

> The way to "fix" auto-refinement is to invoke
> auto-refinement in a diff-mode-hook, as suggested earlier. The bug
> reporter didn't like that <snip>

Probably because auto-refinement is default behavior that got broken.

> I'm not sure
> where the pre-diff content issue came from. Likely it came up because
> the patch that was in the BTS for years wasn't what ended up being
> merged, so I haven't sufficiently tested it. Lesson learned.
>
> I consider the current behavior a significant improvement in usability,
> but if there's a consensus that it's a step backward, then I'll go back
> to carrying this patch in my local tree. Let me ask the few people I
> know who would be using this code at all to get at least anecdotal
> feedback.