skim split-match and FzfLua grep_projects work great together

[LoricAndre]

Quick disclaimer: I'm the maintainer of skim, so I'm definitely biased.

skim now has a --split-match flag that will match parts before and after a delimiter (: by default, can be changed by passing it as an argument to --split-match). This means that running FzfLua grep_project fzf_args='--split-match' allows you to do stuff like this without regex:

This will search for the exact nightly word in all the files matching !CHANGELOG (so excluding the changelog file). This can be used to search for patterns in specific folders, file types etc.

Setting it by default might be too big of a change, but at least it's out there !

[ibhagwan]

I must admit I didn’t fully understand the value in the option until now, pretty cool :)

[RAV64]

Hi - I got interested in updating my setup from fzf to skim. Unfortunately I could not figure out how to send all the results to quickfix list after changing fzf_bin to sk. Previously I got this done with:

keymap = {
	fzf = {
		["ctrl-q"] = "select-all+accept",

But now this gives an error of:
[Fzf-lua] unsupported action: ' nvim/init.lua', type:nil

As skim is (semi?) officially supported, it would be nice to either have these commands abstracted or to make it easier to understand what I need to do. 😄

Thanks a lot to both of you, amazing work 👍🏻

[LoricAndre]

I won't be able to answer you, all I know is that select-all definitely is an action in skim. I expect that accept should take an argument here to indicate what to do with the result, you should be able to find which one by browsing fzf-lua's code

[LoricAndre]

Maybe something using the actions config section and a function that uses act("select-all") and file_sel_to_qf ?

[ibhagwan]

I’ll check what happens here when I get a chance.

The better way to achieve select all is define it like we do in fzf, define it in the actions.ctrl-q directly as { fn = FzfLua.actions.file_edit, prefix = "select-all" }.

I will also verify the above works with skim, this requires fzf’s print action but since skim has accept(ctrl-q) we can make it work (if the code doesn’t handle it already).

[RAV64]

Thanks for the follow-up, I know this is not a help channel, but I personally find the "how" behind this functionality a bit convoluted which is why I'm advocating for a bit simpler process for configuring this, as people most likely just want to have a working setup and move on.

I was able to send all results to QFL with this setup based on your comment @ibhagwan - Thanks 👍🏻 Even here understanding, why these dont go to keymap.fzf|builtin, if this action could be provided only once for all pickers, or why the file_sel_to_qf is defined, but the "select-all" is given as string eludes me 😄

	actions = {
		files = {
			true,
			["ctrl-q"] = { fn = fzf.actions.file_sel_to_qf, prefix = "select-all" },
		},
		grep = {
			true,
			["ctrl-q"] = { fn = fzf.actions.file_sel_to_qf, prefix = "select-all" },
		},
	},

And please don't get me wrong, parts of the answers to my questions are clearly documented in the readme, with comments like this fzf '--bind=' options, I would just like to point out the end-user might not want to deal with the bind options, but instead define results they are interested in.

[ibhagwan]

Even here understanding, why these dont go to keymap.fzf|builtin, if this action could be provided only once for all pickers

You don’t need actions.grep, this is getting ignored, `actions.files’ applies to all file-like pickers (not everything is files, think commands, highlights, etc).

You can then individually overwrite a single picker by supplying its own actions table, for example if you wish ctrl-q to do something else in grep you’d define grep.actions.ctrl-q.

As for keymap.fzf these go directly to the fzf `--bind’ args.

The prefix is an fzf bind string to run before the fzf-lua action so in fact it will run select-all+<fzf_lua_command>+accept(ctrl-q).

I 100% agree this could be simplified as this requires understanding of the “under the hood” which isn’t straight forward, the issue is this will be a lot of work and a breaking change (+potential auto migration from old style to new) which is a lot of work without an immediate benefit as it’s just a config simplification so I never got around to it :)

This project is dear to my heart and if a bug or important change comes up I’ll fix it immediately but low ROI config refactor isn’t at the top of my priority ATM.