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

Add keymap for closing buffer of file under cursor #3037

Open
GCrispino opened this issue Dec 26, 2024 · 7 comments
Open

Add keymap for closing buffer of file under cursor #3037

GCrispino opened this issue Dec 26, 2024 · 7 comments

Comments

@GCrispino
Copy link

Is this a question?
No

Can this functionality be implemented utilising API?
If I understood correctly, no.

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
I believe it might be useful to add a keymap to close the buffer associated with the tree cursor, if such buffer exists.

If this cannot be done, might be useful to have this implemented in the API so a custom keymap can be added.

Describe alternatives you've considered
As mentioned, adding a custom keymap using an API method that can achieve this, if possible.

Additional context
I've done a draft implementation of this in a PR in my own fork of nvim-tree: GCrispino#1

It adds an API method at Api.node.close.close_file_buffer and a keymap to <C-c> that calls this method.

If the maintainers believe this is worth adding, I'd be happy to create a PR here for this

@gegoune
Copy link
Collaborator

gegoune commented Dec 26, 2024

Can this functionality be implemented utilising API?
If I understood correctly, no.

Is that doing what you are after?

vim.keymap.set('n', '<C-c>', function()
  local filename = require('nvim-tree.api').tree.get_node_under_cursor().absolute_path
  vim.cmd({ cmd = 'bdelete', args = { filename } })
end, opts('duffer delete'))

You will probably want to check filename for nil though.

@GCrispino
Copy link
Author

GCrispino commented Dec 26, 2024

Can this functionality be implemented utilising API?
If I understood correctly, no.

Is that doing what you are after?

vim.keymap.set('n', '<C-c>', function()
  local filename = require('nvim-tree.api').tree.get_node_under_cursor().absolute_path
  vim.cmd({ cmd = 'bdelete', args = { filename } })
end, opts('duffer delete'))

Yeah I think so!

You will probably want to check filename for nil though.

About this, would you know how errors are generally reported to the user on nvim-tree? I'm thinking about this case where filename would be nil, in which some message like "no buffer found for file " would have to be printed to the user.

EDIT:
@gegoune based on your code, I came up with the following:

  vim.keymap.set("n", "<C-c>", function()
    local filename = require("nvim-tree.api").tree.get_node_under_cursor().absolute_path
    local buffer_at_filename = vim.fn.bufnr(filename)
    if buffer_at_filename == -1 then
      notify.error(string.format("No buffer coincides with %s", filename))
      return
    end

    vim.cmd({ cmd = "bdelete", args = { filename } })
  end, opts("Close file buffer (if any exist)"))

Do you think this would be a worthy addition to nvim-tree key maps?

@alex-courtis
Copy link
Member

That's a great idea; I think I'd be using that. Let's add it to API.

Can we please keep vim nomenclature and add an extra call for wipe:
Api.node.buffer.delete
Api.node.buffer.wipe

RE error messages, yes please, via notify e.g.

--- Remove a node, notify errors, dispatch events

There will be times when vim won't delete the buffer, and will report a message like E89: No write since last change for buffer 1 (add ! to override)

@alex-courtis
Copy link
Member

alex-courtis commented Dec 28, 2024

vim.cmd({ cmd = "bdelete", args = { filename } })

Calling the command as a function is a little more robust:

vim.cmd.bwipe({ filename, bang = false })

It might also be useful to add an option to the api, something like { force = true }

@GCrispino
Copy link
Author

Hey @alex-courtis , sounds good, thanks for the feedback! I have some questions about your comments:

Can we please keep vim nomenclature and add an extra call for wipe:
Api.node.buffer.delete
Api.node.buffer.wipe

Here do you mean doing something like the code excerpt I added in this comment, but wrapping that into a new API method in Api.node.buffer.delete, and then add another method called Api.node.buffer.wipe, which would do pretty much the same thing, except that it calls bwipe instead of bdelete? Did I get this correctly?

There will be times when vim won't delete the buffer, and will report a message like E89: No write since last change for buffer 1 (add ! to override)

Oh that's true, I hadn't thought of that. Do you have any thoughts on how to handle this? For example, should this not be handled at all (i.e. just call bdelete/bwipe if a buffer exists for the given file and let it error if it has pending changes), or should we add a notify.error call in case the given file has pending changes (i.e. if the buffer is modified)?


vim.cmd({ cmd = "bdelete", args = { filename } })

Calling the command as a function is a little more robust:

vim.cmd.bwipe({ filename, bang = false })

It might also be useful to add an option to the api, something like { force = true }

Sounds good 👍🏼

@alex-courtis
Copy link
Member

alex-courtis commented Dec 30, 2024

Did I get this correctly?

Yup, that would be great. Someone will ask for wipe when they see delete.

For example, should this not be handled at all (i.e. just call bdelete/bwipe if a buffer exists for the given file and let it error if it has pending changes)

If that works we should be fine; vim will effectively notify.error.

If that doesn't work e.g. vim throws an exception, we'll need to wrap it in a pcall and report the error, something like

local success, error = pcall(handler, payload)

@GCrispino
Copy link
Author

GCrispino commented Dec 30, 2024

@alex-courtis @gegoune FYI I've just created a PR for implementing the mentioned API methods: #3040

It's still set as WIP because I haven't run the make commands yet, but the code is pretty much ready.

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

No branches or pull requests

3 participants