feat: syntactic sugar to map funcs over entries & selections

[fdschmidt93]

This PR closes #900 and implements

• toggling, selecting, and dropping all entries from multi selection
• carves out sugar to apply functions (and collect the result) on entries and multi-selections
• furthermore includes vim-bbye action from Buffer close and keep window open #906

[Conni2461]

I am not sure if we need the bbye action or if we should work more with the wiki and have a page with action configurations similar to what fzf does. I don't think we can continue to add super "specific" actions for a "handful" people. We might just blow up the repository.

I'll need think about it and come back to you (I am super busy this week so it might take some time)

[fdschmidt93]

I am not sure if we need the bbye action or if we should work more with the wiki and have a page with action configurations similar to what fzf does.

I personally agree, though I'd be wary that lot of users wouldn't read a wiki (or something similar) and just raise another issue or reddit post (why is grepping slow on large repos? 😆) Maybe an extension that just loads all picker-specific actions appealing to the largest user base is most straightforward; users can then opt-out/remap if something doesn't suit them (and my guess is most actions would just be ignored since a user doesn't care for them).

I'll need think about it and come back to you (I am super busy this week so it might take some time)

No worries, I'll pick this up again then.

[Conni2461]

I would prefer a good structured wiki. The users who, don't read manual will always exist, it doesn't matter if its in the docs as unmapped action, wiki as snippet or an extension as unmapped action. We just need to have a good wiki structure, with a table of content, etc and when the question/issues come we can just like into the wiki and close.

Also, with a wiki, people can just setup things they actually want and maybe while copy and pasting the code, maybe they learn something :)

I try to set up the wiki that way on sunday. I haven't made any decisions on on bbye yet tho

[fdschmidt93]

Any idea how to fix this "flickering" on drop_all that sometimes (not always) occurs? It's cleared once the cursor is moved. From the debugging I've tried it's related to clearing the extmarks here, though I haven't yet had the time to think this through with a meaningful fix as I also haven't used that highlighting api yet.

flicker-2021-06-29_17.33.35.mp4

[fdschmidt93]

Is there a more clear verdict whether #793 is something we would want in telescope? With the action_utils we can easily refine in a simple manner.

function actions.refine(prompt_bufnr)
  local current_picker = action_state.get_current_picker(prompt_bufnr)
  -- select our filter entries
  actions.select_all(prompt_bufnr)
  current_picker:reset_prompt()
  -- invert selection
  actions.toggle_all(prompt_bufnr)
  -- remove inverted selection
  current_picker:delete_selection(function() end)
end

There is minimal flickering from intermediate highlighting (could always be made optional in select_all or toggle_all) and alphabetical (?) resorting of entries, which I personally think is fine, but happy to try and address the latter if desired.

Happy to add it to the PR if desired.

[Conni2461]

I still we shouldn't do #793 because its less performant than using and from fzf-native. But tj and i talked about being able to do live_grep or lsp_dynamic_workspace_symbol and then fuzzy find over the "live" results. So can you wait a little bit longer.

Also i think its out of scope for this PR, we should keep prs smaller.

None the less you have the util functions twice now, once in the actions/init.lua file and once in actions/util.lua

[fdschmidt93]

Ok, fixed. I didn't finally clean up yet as I was waiting on feedback for vim-bbye, whether to keep the mapping or not, and whether there's something to do about the mini-flickering as shown above or would be ok as is.

[fdschmidt93]

To simplify things I've now removed the mapping and vim-bbye action. The mapping can of course be always set by the user and the action will make its way into the wiki eventually.

The highlighting issue referred to above is a separate issue, which stems from removal of highlighting extmarks, and any later fix of that should not effect this PR.

[fdschmidt93]

I circled a bit around our issue of how to collect the return values, only to realize the "burden" is probably best put to the user as it's too easy to just write what he/she want's to do with the output, as opposed to solving the problem for every case.

Stupidly funny side notes:

• Lua cannot store 1 as a key? In practice it doesn't matter, but a() from your above function returns something funny on careful consideration.
• If you ever cared on how to check how many values are returned, it's gets a bit tedious in a practical use case

[Conni2461]

Lua cannot store 1 as a key? In practice it doesn't matter, but a() from your above function returns something funny on careful consideration.

Thats just false. Lua always stores things in keys. So a list starts has keys 1 ... n inspect just omits 1 .. first occurrence of nil because it can be omitted. A simple for k,v pairs(tbl) do should demonstrate that.

If you ever cared on how to check how many values are returned, it's gets a bit tedious in a practical use case

for a list (a table starting with the key one) for # it returns how many values till first nil. That was whole point with the table with holes and why i said we need to change it but yeah

[fdschmidt93]

Thats just false. Lua always stores things in keys. So a list starts has keys 1 ... n inspect just omits 1 .. first occurrence of nil because it can be omitted. A simple for k,v pairs(tbl) do should demonstrate that.

Maybe a bit badly phrased, that's why I said it doesn't matter. But yeah, good to have it in full detail 😆