Navigating the Preview Window

[ttytm]

As a user, I would like to be able to scroll in a preview window when the contents of a buffer displayed in the preview exceed the height of the preview window.

This could be achieved by extending the command list with scroll-commands (those could behave similar to what Telescope does by default with <C-d> <C-u>) or by adding the ability to move into the preview window (similar to what many "hover" actions do when double pressing the hover key).

[cseickel]

Personally, I would prefer to move the cursor into the preview window so I could use the full range of movement and search commands.

From the neo-tree side it would be simple to add a command that would focus the preview window, which can be mapped to whatever the user wants. I'm not sure if the window might close on you the way it is written now, there may be a small amount of work there to prevent that.

Once you are in the preview window, it would be nice to add just two extra mappings:

• One to close the window and end preview mode
• One to move the cursor back to neo-tree

I'm not sure if there should be extra config options for the preview window mappings or if it would be better to just read the mappings on the Neo-tree window and reuse whatever is mapped to close_window and focus_preview.

There's also nothing stopping us from also adding scroll commands that work without focusing the window. We can do either one or both.

[ajitid]

There's also nothing stopping us from also adding scroll commands that work without focusing the window. We can do either one or both.

I think it'd be better to only provide controls for scroll and not go for full-fledged ones. Otherwise, we'd need to wrestle with variables to ensure the preview window remains read-only. One can always open the file to do search and other operations, and this also aligns with the previewer options that fzf-lua and vim-bqf give.

[ttytm]

@ajitid sounds reasonable, if I can grab a free moment later today, I'm starting with the implementation. Otherwise, I can schedule a few minutes every day in the coming week 👍

[ttytm]

In the end, I decided to start with the approach also preferred by @cseickel. To name a few reasons for this:

• I can certainly see myself moving into the preview window and yank some content, as I found myself doing this now and then with lsp hover/error dialogs.
• Time constraints, it was easier to implement a focus command.
• On second thought, I don't think the preview window needs to be read-only.

We can extend navigation in the preview window incrementally. A command to scroll in the preview while the tree is focused can still be implemented.

[dudicoco]

@ttytm @cseickel the current implementation is problematic in git status mode as for each file that you are reviewing you need to use l within the preview mode, navigate within the file, then hit a different key combination in order to return to the tree.

I believe a better experience would be to either to allow binding ctrl-u / ctrl-d to the preview window or make the l keybinding toggle focus on the preview window.

[alexveden]

I believe a better experience would be to either to allow binding ctrl-u / ctrl-d to the preview window or make the l keybinding toggle focus on the preview window.

I made a pull request with default bindings to <C-b>/<C-f> as least conflicting. Hopefully it will get merged soon.

[dudicoco]

@alexveden thanks!

[dudicoco]

So after trying out the preview scroll with git_status I realized this doesn't really solve the problem of looking at git diffs easily.

I'm using gitsigns to display inline diff within the preview window (toggle_deleted + toggle_linehl + toggle_word_diff).
I would like to easily move between the different changed hunks within the preview window (next_hunk).
Is there a way to send custom commands for navigating the preview window without moving into it?