Mark Oteiza writes: > 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. While it may have made fixing the issues > mentioned in the commit message easier, the changes to what "n" and "p" > do at the beginning and end of a diff are not documented, and I didn't > see any discussion of it in the associated bug. > > I contend that the new behavior is inconsistent with the behavior of > other outline/thing-with-headers type things in Emacs. outline-mode, > org-mode, and rst-mode are the first ones that come to mind. Can you give a specific example of interaction in any of these modes that is analogous to the off-by-one behavior you're referring to? The fundamental question is what hunk diff-mode should think the point is looking at, when it is in some non-diff message above the first hunk. The answer I chose for the new navigation logic is "first hunk". You could also choose "invalid hunk, not a hunk at all", which would imply that C-c C-a and M-ret and such shouldn't work there. Better suggestions welcome. > It's also not clear how the introduced oddity with auto-refine is going > to be resolved, unless a way is found to autorefine the first hunk > without there being any user interaction. Then opening a diff has > inconsistent auto-refining from the start. I don't use auto-refinement, so didn't notice the breakage. Will look at it in a bit. In the meantime, I'm attaching a patch to address the 2nd point in the bug report (25105). This serves to treat the junk before the first hunk (i.e. commit message from 'git format-patch') as a file header. Looks reasonable?