diff display scroll position shouldn't be influenced by file scroll position

[emmanueltouzery]

When I call :lua require('diffview').open() and select to display the diff of a file X, if I have that file currently open in a buffer, and my cursor is, for instance, on the last line of the file.. Then the diff will be opened in this case totally at the bottom of the file. Actually in this case only one line of the diff is visible, a folded line, because changes at the bottom of the file are collapsed. That folded line is displayed totally at the top of the window and that's all that is displayed. That made me think more than once that there are no changes for that file, which confused me as to why would diffview offer that file in its sidebar, if there are no changes.

But in fact there are changes, and if I press C-b a couple of times or scroll up, I can see other lines and the changes.

I'm sure I don't see the full story, but in this case it would be more helpful for me if when a file is selected in the diff view, it's scrolled to the top upon displaying, to avoid this from happening.

[sindrets]

@emmanueltouzery Yes, I've noticed this too. We could certainly move the cursor to the top of the file the first time its diff is opened in a view. In the meantime, you could use this hook in your config to accomplish just that:

hooks = {
  diff_buf_read = function(bufnr)
    vim.api.nvim_win_set_cursor(0, { 1, 0 })
  end,
}

[emmanueltouzery]

thank you for the answer! I've tried your solution, it is definitely better, but it doesn't quite work all the way. It only works when one selects the file on the left pane, by pressing enter. However, if I'm in the file A, and run :lua require('diffview').open(), diffview will directly select that file (which is great!). And apparently this hook is not triggered at this point, when the file is "auto-selected" by default by diffview. But apparently, only when the user manually selects the file when pressing enter in the left pane. So it's only a partial workaround, FYI.

[sindrets]

@emmanueltouzery The hook definitely runs. You can easily tell by adding a print call. But I can see that cursor() doesn't work in the situation you describe for some reason. However, changing it to vim.api.nvim_win_set_cursor(0, { 1, 0 }) works.

[emmanueltouzery]

yes, that seems to do it, thank you!

[sindrets]

@emmanueltouzery Just wanted to let you know that this has now been implemented, so you no longer need the hook :)