Skip to content

[Feature request] nvim-tree hijack_cursor functionality #604

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

Closed
Racle opened this issue Nov 11, 2022 · 8 comments · Fixed by #955
Closed

[Feature request] nvim-tree hijack_cursor functionality #604

Racle opened this issue Nov 11, 2022 · 8 comments · Fixed by #955
Assignees

Comments

@Racle
Copy link

Racle commented Nov 11, 2022

"Keeps the cursor on the first letter of the filename when moving in the tree."

In my opinion it's little easier (or more "pleasant" to eye) to follow where cursor is when it's always on first letter of dir/file.

When moving cursor with jk and open/close nodes with hl, with this feature in nvim-tree that feels much better.

https://github.com/nvim-tree/nvim-tree.lua/blob/9e87ee2d6e86f37ff09cb74ec7dcf2ac984a01e9/doc/nvim-tree-lua.txt#L478

@Racle Racle changed the title [Feature request] nvim-tree hijack_cursor functionality [Feature request] nvim-tree hijack_cursor functionality Nov 11, 2022
@miversen33
Copy link
Collaborator

Adding Permalink

@miversen33 miversen33 added the enhancement New feature or request label Feb 4, 2023
@miversen33
Copy link
Collaborator

This should be relatively trivial to do.
In theory all that is needed is some simple string logic to find the first location in the line of the "name" of the node, and set the col value to that instead of 0.

Source code link

This is a very small area for touching, basically add a bit of logic after 439 (the space indent) to determine the correct column for the cursor.

@ashkan117
Copy link

Attempting to tackle this one as an fyi

@miversen33
Copy link
Collaborator

@ashkan117 When you have some code that you would like to have reviewed, feel free to submit a PR against the main branch

I will see the PR but also I am really bad at replying to notifications so feel free to tag me on it so I can review it :)

@ashkan117
Copy link

ashkan117 commented Feb 5, 2023

Am I right in guessing that the focus node is not triggered with hjkl movements? I can see that eventually something triggers the method then the col gets updated to the correct thing. Other than that things look like they work as expected

@miversen33
Copy link
Collaborator

I would not think that hjkl would trigger the focus_node function.

I can see that eventually something triggers the method then the col gets updated to the correct thing.

I don't know what you mean here. Is this an issue? If so, could you elaborate? I'm glad you're getting progress either way :)

@cseickel
Copy link
Contributor

cseickel commented Feb 6, 2023

Am I right in guessing that the focus node is not triggered with hjkl movements?

That's correct. It is used to restore the focused node after a refresh, for the "reveal" commands, and for the follow_current_file option.

I can see that eventually something triggers the method then the col gets updated to the correct thing.

There are many things that may trigger a refresh, which will call focus_node. If you use follow_current_file then that will move the cursor every time you change buffers.

@ashkan117
Copy link

Ok that makes sense. I think in my case the reveal command was triggering the change I saw. Is there a place I should move my logic then? Since in my head the col should be reevaluated on moves and focus_node?

Basically my issue is that I am not sure where to put the logic that determines the col of the node

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants