Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Jumping to the next/previous modified file in git worktree #342

Closed
williamboman opened this issue May 2, 2022 · 12 comments
Closed
Labels
enhancement New feature or request

Comments

@williamboman
Copy link

Hello, thanks for this plugin! I looked through the docs and previous issues but couldn't find this anywhere, so apologies if it's been discussed already.

One feature I used a lot in https://github.com/kyazdani42/nvim-tree.lua was the ability to jump between modified files in the git worktree through the default keymaps ]c & [c. I think it'd be nice for neo-tree to provide the same functionality! Not sure how to handle jumping to a file that is inside a tree that isn't expanded (should neo-tree automatically expand all directories until the node or should it just select the closest currently available parent node?).

@cseickel
Copy link
Contributor

cseickel commented May 2, 2022

There is this discussion: #317

There is also the git_status source. If you configure it to show in the same spot as the filesystem source, then you can just have a mapping which toggle between the two.

Jumping to a node that isn't visible is not a problem if we use the "reveal" or "follow" logic. Are you looking to make these jumps to nodes within the tree, or to open files without focusing the tree?

@cseickel
Copy link
Contributor

cseickel commented May 3, 2022

This caught my interest and I ended up add commands for this, mapped to [g and ]g by default:

[g      = prev_git_modified: Jump to the previous file reported by `git status`
                             that is within the current working directory.
                             This will loop around if you are on the last one.

]g      = next_git_modified: Jump to the next file reported by `git status`
                             that is within the current working directory.
                             This will loop around if you are on the last one.

They will open the folders if needed when jumping to the next git modified item.

It turned out the hardest part was figuring out which item is "next" when viewed in a file tree.

NOTE: this is in the main branch. I am a little suspicious that there may be a glitch with git status updates in main right now, so be warned if you try it out.

@williamboman
Copy link
Author

williamboman commented May 3, 2022

Awesome 👏 !! It seems like it won't expand the folder when trying to jump to a file that is within a collapsed folder, the cursor just doesn't move. It seems like it is however able to identify the file (I'm assuming as it's printing correct stuff). It starts jumping to the nested file if I manually expand the necessary folders to expose the file in the tree.

neovim version: NVIM v0.8.0-dev+94-g7502f1cae
neo-tree commit: 17b0b0e

@cseickel
Copy link
Contributor

cseickel commented May 4, 2022

It seems like it won't expand the folder when trying to jump to a file that is within a collapsed folder,

It's supposed to expand the folder. If it doesn't it means something is broken. ☹️

It seems like it is however able to identify the file (I'm assuming as it's printing correct stuff).

Oops, forgot to remove a print statement!

neovim version: NVIM v0.8.0-dev+94-g7502f1cae

I am still working on a 0.7 nightly. I'll update to the latest and see what happens.

@cseickel
Copy link
Contributor

cseickel commented May 4, 2022

I tried it out on NVIM v0.8.0-dev+112-g13520aae1 and it works as expected, which means it will open folders to get to the next git item. One flaw that I am aware of is that it will break if the next item in the list is a hidden file. Could this have anything to do with that problem?

It could also be that the reveal functionality is just generally not working for you. Does it work when you issue a :Neotree reveal command for a file that is not currently visible in the tree? Also, are you on Windows?

It also seems like added files are not included in this, but that is not affected by whether the folder is open or not.

@cseickel cseickel added the enhancement New feature or request label May 4, 2022
@cseickel
Copy link
Contributor

cseickel commented May 4, 2022

One flaw that I am aware of is that it will break if the next item in the list is a hidden file.

That was actually just fixed. As soon as I typed it I knew that was not how it should be. Not just for this feature but in general. From now on, if you take some action to "reveal" a file, it will be shown even if it was a hidden file.

@williamboman
Copy link
Author

I can't really piece together what could be the problem, but here's a recording of me trying to jump ]g [g:

https://asciinema.org/a/antkioEvw65STRaqAM6R5HWYZ

It almost seems untracked files aren't recognized, and jumping only works consistently if folders are expanded?

On commit 036d5b5 and I'm on macOS!

@cseickel
Copy link
Contributor

cseickel commented May 5, 2022

This was closed automatically because I released the commit that mentions it, but I will re-open now until we confirm that it works correctly.

I made further updates to this functionality that may fix the issue for you. The expectation is that using the commands will always jump you to the next item in the git status list which is within the current root of the Neotree window. If that item is in a closed folder, it will expand whatever is needed to show the file.

If that doesn't happen for you, could you enable logging and share the portion of the logs where you use these commands? Another basic check is to run :Neotree reveal when on a file that is not currently visible in the tree.

EDIT: I should have mentioned, here is how to enable logging: https://github.com/nvim-neo-tree/neo-tree.nvim/wiki/Troubleshooting

@cseickel cseickel reopened this May 5, 2022
@williamboman
Copy link
Author

williamboman commented May 6, 2022

It definitely seems to be working better! It seems like it refuses to re-expand folders that have been manually collapsed. Not sure if that's intended, but I'd assume it isn't?

https://asciinema.org/a/lHj1oSGyY45YQbYQbBeYCt0e5

commit: 71e3d71

edit: will enable logging, sec

logs: https://pastebin.com/raw/9MPZQ1bX

@cseickel
Copy link
Contributor

cseickel commented May 6, 2022

It seems like it refuses to re-expand folders that have been manually collapsed. Not sure if that's intended, but I'd assume it isn't?

That's what it is! I can't believe this has never come up in my own usage! I guess that for me, once it is expanded I rarely collapse it again. I'll fix this soon.

@cseickel
Copy link
Contributor

cseickel commented May 6, 2022

That should be fixed now. Let me know if you find any more issues with this.

@williamboman
Copy link
Author

Works great! Thank you so much!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants