Skip to content

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

Merged
merged 3 commits into from
Apr 30, 2023
Merged

feat(api): add node.open.drop() #2164

merged 3 commits into from
Apr 30, 2023

Conversation

gegoune
Copy link
Collaborator

@gegoune gegoune commented Apr 23, 2023

No description provided.

@gegoune gegoune requested a review from alex-courtis April 23, 2023 07:25
@gegoune
Copy link
Collaborator Author

gegoune commented Apr 23, 2023

Similar to tab_drop. Has some jarring/redrawing issue at the moment. @alex-courtis Any idea why that might be?

Copy link
Member

@alex-courtis alex-courtis left a 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.

@@ -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.
Copy link
Member

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"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated, good suggestion, thanks.

@alex-courtis
Copy link
Member

Similar to tab_drop. Has some jarring/redrawing issue at the moment. @alex-courtis Any idea why that might be?

See #2164 (review)

Idea:

  • search buffers for file
  • determine whether a window shows that buffer
  • shown: drop
  • not shown: open as normal

I'm not sure that's really worthwhile - adds complexity, as we are second-guessing :drop.

Co-authored-by: Alexander Courtis <alex@courtis.org>
@gegoune
Copy link
Collaborator Author

gegoune commented Apr 24, 2023

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 tab_drop which seems very much workflow oriented (misusing vim's tabs ;).

Something like

node.open(function(node) vim.cmd("drop " .. node end)

@alex-courtis
Copy link
Member

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 node.open follow |nvim-tree.actions.open_file| however there is no need here.

It's more generic than that even. It's a general "do something with a node" function. Maybe node.run.fn ?

@alex-courtis
Copy link
Member

niche case such as tab_drop which seems very much workflow oriented (misusing vim's tabs ;).

We can remove that from documented API if we leave it in there, deprecated.

@gegoune
Copy link
Collaborator Author

gegoune commented Apr 25, 2023

That definitely makes sense! Can you see any issues with functionality such as 'close on open'?

@alex-courtis
Copy link
Member

alex-courtis commented Apr 29, 2023

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.

@alex-courtis
Copy link
Member

@gegoune I'm happy to merge this if you are; it works and is consistent with the other node.open actions.

@gegoune gegoune merged commit 0df384b into nvim-tree:master Apr 30, 2023
@gegoune gegoune deleted the api/drop branch April 30, 2023 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants