Hi all! On 26/07/2025 23:14, Jakub Ječmínek via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Sean Whitton writes: > >>>> Seems like this needs to be investigated before we can proceed. >>> I've tested various scenarios and haven't encountered any issues with the >>> current implementation. It would be great if you could test the change as >>> well, in case there are edge cases I missed. >> I think that we need to see an argument in terms of the definition of >> the file-name-changes backend function that demonstrates that your >> approach will always work: >> >> ;; Return the list of pairs with changes in file names in REV. When >> ;; a file was added, it should be a cons with nil car. When >> ;; deleted, a cons with nil cdr. When copied or renamed, a cons >> ;; with the source name as car and destination name as cdr. > My approach updates the FILE argument only if the file name has changed > in the given revision; otherwise, it keeps the name unchanged. I’m not > sure if it will **always** work, but it does fix the issue at hand. I'm > sorry, but I can't provide any further arguments in favor of this > change. Looking over the bug report again, my previous question was off the mark: it was about longer jumps over revisions - but the 'j' and 'a' commands (which are probably the only examples of such in the tree) specify the target file name explicitly (getting it from the buffer contents), so they should be okay. For the 'n' and 'p' commands, it would usually be fine because the step is often 1 revision. Anyway, that patch seems to fix stepping forward once across a name change, but not farther, nor stepping backward over such a change. To reproduce, add steps like this to the original setup: $ echo " morecontent" > newdir/file.txt $ git commit -m 'Edit after the move, adding second line' And then this to the reproduction: 5. Press 'n' again. 6. Press 'p' twice. It seems the fix is to move the change from 'vc-annotate' to 'vc-annotate-warp-revision' (previously mentioned by Jakub), and to update the new function to handle both directions. Please try out the the attached update, it seems handle both. I did some quick testing with Mercurial too.