[harpoon 2] Ability append item to list with any index

[kaiphat]

What issue are you having that you need harpoon to solve? I would like to try using harpoon like window manager. I mean, I want to know exactly, that my file will be available by my shortcut, but i don't have opportunity to connect buffer with necessary key. For example:

<leader>hQ -> list:append(1)
<leader>hq -> list:get(1)
<leader>hW -> list:append(2)
<leader>hw -> list:get(2)

In other words don't use list like array, but like map.

Why doesn't the current config help? Nope

What proposed api changes are you suggesting? Change append method or better to add another one like insert. And mb change next and prev methods to skip empty indexes in list. And length.

[rtc11]

I need this.

I want to be able to do something like this, because the item I am appending is not in the buffer:

require('harpoon'):list():append({ value = rel_file_path, index = 3 })

-- or

require('harpoon'):list():append({ value = rel_file_path }, 3)

[kaiphat]

Actually in lua there isn't difference between list and object. So it would be like that:

require('harpoon'):list():append({ value = rel_file_path, index = 'q' })
require('harpoon'):list():append({ value = rel_file_path, index = 'any_specific_index' })

[willothy]

Seems like #400 somewhat addresses this?

[kaiphat]

Yes, it's similar, but it doesn't allow this case: i have empty list, but i want to add concrete file to index 3, because i have keymap for this index

[kaiphat]

I did simple local implementation without ui (actually, i have never used it), so i don't need harpoon. https://github.com/kaiphat/dotfiles/tree/master/nvim/lua/local_plugins/marks Some features:

• add mark with any index (number, char, string) (see Manager#add_keymaps)
• unique marks for different git branches
• i decided to save row, col like usually marks

• you can add current mark index to statusline like this

  local function get_marks_component()
  return {
      enabled = function()
          return require('local_plugins.marks').active_mark_index ~= nil
      end,
      provider = function()
          return require('local_plugins.marks').active_mark_index
      end,
  
  }
  end

• you can load this with lazy

  return {
  dir = './',
  event = 'BufReadPre',
  config = function()
      require('local_plugins.marks'):setup()
  end,
  }

  I'm not going to do separated plugin, but who knows:) If you have some questions, i can answer, but i think you can find any information in my config.

[ThePrimeagen]

I have to have a very compelling reason to accept any form of this

Please convince, as I don't want the complexity and I don't think the use case is real

[kaiphat]

The main problem for me is i can't memorize items order:) So if i have 4 items in list i can't open necessary file by index, only through cycling. Also, i can't change item for index 2 for example it means that if i filled list incorrectly i should cleat this and fill one more time.

[ThePrimeagen]

We have replace for this operation

[sartak]

For me it boils down to wanting to pick which hotkeys go to which files (so I can consistently have 1 to go the implementation, 2 to the interface, 3 to the test, etc), rather than having to remember what harpoon happened to give me.

[kaiphat]

@sartak great explanation!

[lpanebr]

I'd like list_height and allow_empty_items settings so that I could map any file to any key-finger combination regardless, like shown below.

For me this would allow me to map my index, middle and ring fingers individually to different file sets as I see fit.

[rtc11]

Indexes have many use-cases and enables a lot more customizing.

For developers that hates popup menus:

<C-ah> = register buffer to h <C-h> = goto buffer h <C-ch> = clear register h (preserve the others)

For developers that love popup menus:

[thomazmoura]

I'm trying to move from harpoon to harpoon 2 and I'm having a hard time believing this is not built-in in harpoon 2 since it was working just fine on harpoon 1. So, am I missing something obvious or is the following code really not doable anymore in any way in harpoon 2?

vim.keymap.set('n', '<M-j>', '<cmd>lua require("harpoon.ui").nav_file(1)<Enter>', opts)
vim.keymap.set('n', '<M-k>', '<cmd>lua require("harpoon.ui").nav_file(2)<Enter>', opts)
vim.keymap.set('n', '<M-l>', '<cmd>lua require("harpoon.ui").nav_file(3)<Enter>', opts)
vim.keymap.set('n', '<M-;>', '<cmd>lua require("harpoon.ui").nav_file(4)<Enter>', opts)

vim.keymap.set('n', '<M-S-j>', '<cmd>lua require("harpoon.mark").set_current_at(1)<Enter>', opts)
vim.keymap.set('n', '<M-S-k>', '<cmd>lua require("harpoon.mark").set_current_at(2)<Enter>', opts)
vim.keymap.set('n', '<M-S-l>', '<cmd>lua require("harpoon.mark").set_current_at(3)<Enter>', opts)
vim.keymap.set('n', '<M-:>', '<cmd>lua require("harpoon.mark").set_current_at(4)<Enter>', opts)

Just to clarify my use case is that often for each feature I'm developing I have the same types of files open depending on the type of feature: when developing APIs I often have the test (j), the class I'm implementing (k) and dependencies it calls (l and ;), if I'm developing an UI with Angular I'll have the html (j), the component logic (k) and services related to the feature (l and ;).

Having the ability to map a key to a type of file depending on what I'm developing is what made me love harpoon 1 and with the above code it's easy to do it just by adding shift to set or replace the index. If for harpoon 2 I have to manually reorder the files using the menu whenever I want to change a file I'm not sure if the upgrade will be worth it for me.

[ThePrimeagen]

I'm planning on doing another round of harpoon development and rounding off any of these bugs in the next 2 weeks

I very well may add this feature

[rofrol]

@thomazmoura harpoon:list():replace_at(1)?

[thomazmoura]

@thomazmoura harpoon:list():replace_at(1)?

You mean like the one on #400 ? It would be fine by me.

But so far it seems to me that Primeagen won't fix this because the way it is now already suits all his needs - and it doesn't seem like having things that were supported on version 1 be unsupported on version 2 is a big deal for him, which is reasonable. I'm still using version 1 and it's being suiting me as well so I'm fine with being "stuck" on version 1 for now (it seems like the new features don't really affect my workflow anyway).