harpoon
harpoon copied to clipboard
split/tab mappings
The issue https://github.com/ThePrimeagen/harpoon/issues/381 was closed but it doesn't seem to be addressed. There was a comment about a PR that had just been closed but there was no link so I couldn't see what was meant. Maybe it is fixed but not anywhere I can see. Since I can't reopen it I'll make a new issue here.
Harpoon would not be useful to me without the ability to open files in (v)splits and tabs. If there is a way to configure keymaps through options then that would need to be documented somewhere.
I haven't documented it but feel free to look at the code, it's quite simple.
config.lua (on phone, not easy to get links)
You will see a option bag passed into select Select is called from the list Pass an option into the list method select
I'll get on documentation at some point.
Rockin!
@ThePrimeagen This is closed in error. Just to be clear, the goal here is to set keymaps such that opening in (v)split or tab can be set by whatever key you like. Right now forcing config.lua:116 to run 'vim.cmd("vsplit")' does nuffink! Pressing Ctrl+v in a harpoon list tries to set a visual block. Attempts to set options have failed to show in the logger output. Doesn't seem simple to me!
@ThePrimeagen This is closed in error. Just to be clear, the goal here is to set keymaps such that opening in (v)split or tab can be set by whatever key you like. Right now forcing config.lua:116 to run 'vim.cmd("vsplit")' does nuffink! Pressing Ctrl+v in a harpoon list tries to set a visual block. Attempts to set options have failed to show in the logger output. Doesn't seem simple to me!
The issue is fixed by #399, which was also closed in error. The menu needs to be closed before the list's select
method is called.
Wait.. I'll look into this. My bad, my bad
Let me review this because I am skeptical that order should matter like this. Must be another issue
I put together a working pr here - https://github.com/ThePrimeagen/harpoon/pull/430
Wait.. I'll look into this. My bad, my bad
Let me review this because I am skeptical that order should matter like this. Must be another issue
@ThePrimeagen I have done a little debugging and the underlying issue is caused by the BufLeave
autocmd. Order definitely matters when it comes to autocmd trickery.
When you call vsplit
a new split window is created with the current buffer (the menu buffer). When you call nvim_set_current_buf
the BufLeave
autocmd is executed, the menu is closed, and nvim_buf_delete
is called before the new buffer is set in the window. nvim_buf_delete
closes the windows containing deleted buffers, meaning that the window is closed before it ever contains the new buffer.
No split appears to be created, even though one was created for maybe a few milliseconds, because the splits are always closed immediately by nvim_buf_delete
.
The options, as far as I can tell, are:
- This fix
-
vim.schedule_wrap
theBufLeave
autocmd callback and callclose_menu
instead oftoggle_menu
in it to ensure the menu is only closed afterselect_menu_item
is executed.