nixvim

nixvim copied to clipboard

Harpoon allows appending buffers to the jump list, which is implemented in nixvim via plugins.harpoon.keymaps.addFile

There is also a secondary option, that allows to directly set an entry on the jump list via require('harpoon.mark').set_current_at(<index>). This functionality is currently missing from nixvim

This PR aims to add that functionality via plugins.harpoon.keamaps.setFile

Please note that this is my first ever pull request, so any feedback is greatly appreciated! (e.g. I'm unsure about reusing mkNavMappings, since this is not technically navigation itself)

nix flake check --all-systems runs through x86_64-linux and aarch64-linux, but then stops at x86_64-darwin and aarch64-darwin, since I'm not on a darwin system. If there is a way for me to run these checks, feel free to let me know and I will do so.

nix flake check --all-systems runs through x86_64-linux and aarch64-linux, but then stops at x86_64-darwin and aarch64-darwin, since I'm not on a darwin system. If there is a way for me to run these checks, feel free to let me know and I will do so.

These are run by the CI when pushing to a PR, no need to run all checks locally.

Looks like the Darwin test is failing, but I think that might be unrelated.

I'm unsure about reusing mkNavMappings, since this is not technically navigation itself

All mkNavMappings does is create a keybinding where the key is taken from the config value and the action is raw lua produced by the genLuaFunc you define (the one that takes id as an argument). Maybe mkNavMappings is a misleading name...

Overall the changes look good to me. Have you tested them locally; i.e. do they behave as you expect when running nvim?

i'm not sure it's a great idea adding this keymap as it's undocumented in harpoon. it's probably undocumented for a reason. when i try to use it, it replaces the current mark with (empty), which is unwanted

Sorry for the late reply, I figured GitHub would send me an email notification since I'm subscribed to the thread, but I didn't actually get one, so I'm only seeing this now.

Overall the changes look good to me. Have you tested them locally; i.e. do they behave as you expect when running nvim?

I'm not experiencing the same issue as 4lxs described above, however, it does behave in a somewhat unexpected way:

When setting a mark like this, the mark itself does get set correctly, but all previous entries that are not assigned are instead replaced with (empty). E.g. if entry 1 is set, and then entry 4 is set using this, then entries 2 & 3 will be (empty). Attempting to jump to them then opens a new buffer called (empty) instead of the expected behaviour (nothing happens).

This occurs when issuing the command manually, so I'm assuming that's an issue with the function itself

As 4lxs pointed out, this appears to be undocumented, and there are some unexpected side effects. So personally, I'd also be ok with closing this PR, as I've since found another way to achieve the functionality I want and don't actually need this anymore

As 4lxs pointed out, this appears to be undocumented, and there are some unexpected side effects. So personally, I'd also be ok with closing this PR

No problem, thanks anyway for your efforts! I'll close this then, feel free to open another issue/PR if needed.