-
-
Notifications
You must be signed in to change notification settings - Fork 625
feat(api): add node.open.drop()
#2164
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
Conversation
Similar to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely works:
open_file.quit_on_open
update_focused_file
Same behaviour as :e something
in the tree window.
view._prevent_buffer_override()
is firing. That is the source of the jarring.
doc/nvim-tree-lua.txt
Outdated
@@ -1545,6 +1545,15 @@ node.open.vertical() *nvim-tree-api.node.open.vertical()* | |||
node.open.horizontal() *nvim-tree-api.node.open.horizontal()* | |||
|nvim-tree-api.node.edit()|, file will be opened in a new horizontal split. | |||
|
|||
node.open.drop() *nvim-tree-api.node.open.tab()* | |||
Switch to window with selected file if it exists. | |||
Open file in current window otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is strictly correct, however view._prevent_buffer_override()
will always fire to eject the newly opened file.
How about "Open file otherwise"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated, good suggestion, thanks.
See #2164 (review) Idea:
I'm not sure that's really worthwhile - adds complexity, as we are second-guessing |
Co-authored-by: Alexander Courtis <alex@courtis.org>
Another idea here is to generalise open functionality. Accept callback/function as an argument which will be responsible for opening files, users then will be able to do whatever they want and we can provider wrappers for currently existing functionality. This would work very well for niche case such as Something like node.open(function(node) vim.cmd("drop " .. node end) |
I like that. Fits with our "API instead of specific functionality" push. The other It's more generic than that even. It's a general "do something with a node" function. Maybe |
We can remove that from documented API if we leave it in there, deprecated. |
That definitely makes sense! Can you see any issues with functionality such as 'close on open'? |
Anything could go wrong, depending on what the user does in the function. We know it works for the basics like :drop and quit_on_open. It's really up to the user. This opens up all sorts of options for the user e.g. window placement with no additional plumbing required. |
@gegoune I'm happy to merge this if you are; it works and is consistent with the other |
No description provided.