• Title for grep/file commands. Same as preview window titles with current file, it would be cool to have main window title for such commands with lets say current directory. It's not like you don't know in which directory you are, but sometimes when you play with :cd or with filemanagers inside nvim it can help by the glance of the eye to see if you are searching in the right directory. Maybe it also would be good to move fzf --promt (and leave it to be only >) for all commands to the window title instead, so it would not shift the search promt and maybe visually would be more appealing, at least as an option for the configs that uses window borders.
• In preview window highlight only mathced line. Default preview window (not bat etc) currently highlight so called cursor line, but if you scroll preview window this highlight follows scrolling. But it makes no sense to highlight this lines, this highlighted line is not the position in a file where you will jump if you scroll preview window and then <CR>, it still would jump to matched line before you made any scroll. So for me cursor highlighting make no sense in the preview window and personally it would be less confusing to just highlight the line where the match is happening.

Great ideas @monkoose, I’ll give this more thought after I’m done working on the API/Advanced Wiki (WIP in the develop branch).

Hi @monkoose, the second item (preview line highlight) was completed in https://github.com/ibhagwan/fzf-lua/commit/519dbf067bc54a19f5bd57fa86dedecf13bfb1fe, there's also a new highlight option winopts.hl.cursorlinenr if you wish to change the highlight of the cursor line number (useful if you set a custom winopts.hl.cursorline and you want the number highlight to match).

Feedback welcome.

At first glance works as i expected it to work. Thank you.

Adding to this, it would be awesome if the title for main/preview window could be aligned.

Adding to this, it would be awesome if the title for main/preview window could be aligned.

By aligned you mean left/right/center?

The plug-in has reached stability and everything is working great for a while I’ve been avoiding making such a bug change, I’ll get to it one day when I get inspired :)

Adding to this, it would be awesome if the title for main/preview window could be aligned.

By aligned you mean left/right/center? Yes The plug-in has reached stability and everything is working great for a while I’ve been avoiding making such a bug change, I’ll get to it one day when I get inspired :)

I don't see how that is a bug change. Its just a matter of calculating the position of the title for the given space.

I wanted to contribute to add title to the main windows, but no idea how that will be done. Modifying borders for title is not a great idea i guess, brings in the unnecessary complexity ( don't mind if am saying something wrong ).

But title alignment for previewer should be easy enough i guess ( i hope ).

I don't see how that is a bug change. Its just a matter of calculating the position of the title for the given space.

nvim_open_win does not support titles, the way the preview title works is by layering 2 windows on top of one another and drawing the border/title manually on top of it, the way the window code is currently written is not optimal for this as there are so many edge cases (with/without preview, full screen, vertical/horizontal splits, etc), my plan was to write a custom window class that could just replace nvim_open_win and would do the rest for me - similarly to plenary popup geared towards fzf-lua.

Take a look at this function and you’ll get the idea: https://github.com/ibhagwan/fzf-lua/blob/054c312b1cc327be68045ffc4926133a60ff9b82/lua/fzf-lua/win.lua#L107

@Akianonymus it's just overkill. Then another user request would be not only left/right/center, but 2/3 of the window etc. It can't be perfect for everyone. And it adds more logic. Currently i guess (haven't looked into the code) title just another window at the same row as main float window + column of the main window increased by some value. To place it at something like center/right would require additional calculation of the width of the main window and adding some if bracnhes to support 0.001% of the users who for some reason like text to be at the right side of the window.

For me fzf-lua already overly opinionated. Already ~500 options to set https://github.com/ibhagwan/fzf-lua/blob/054c312b1cc327be68045ffc4926133a60ff9b82/doc/fzf-lua.txt#L352-L936

For me fzf-lua already overly opinionated.

Interesting @monkoose, do you mean opinionated defaults (binds, settings, etc) or missing customizations?

Already more then 500+ options

Doesn’t “opinionated” mean hard set options that aren’t customizable (I.e. author’s “opinion” on how things should be done)?

@ibhagwan bad english (it autocorrect my "optionated" word). I mean it already has a lot of options to choose and set, and i do think that majority of it is never touched by any user so it just complicate codebase. But maybe it's just opinion of the user who do like simplicity over complexity.

Take a look at this function and you’ll get the idea:

https://github.com/ibhagwan/fzf-lua/blob/054c312b1cc327be68045ffc4926133a60ff9b82/lua/fzf-lua/win.lua#L107

Ooh, that went one step ahead, 2 windows, damn. Lots of stitches.

@ibhagwan bad english. I mean it already has a lot of options to choose and set.

Gotcha, IMHO, fuzzy finding framework is a core part your setup and it can be deeply personal for users, there wasn’t any other way, so many obscure requests in issues and I really did my best to accommodate everyone.

Ooh, that went one step ahead, 2 windows, damn. Lots of stitches.

That’s partly due to the double window preview layout so that’s already 3 windows including the main one, now add all the layout options I mentioned above and you’ll understand why.

The win class started when there wasn’t a neovim “builtin” preview window, previews were bat/fzf only, there was also an anchoring bug with 0.5 (fzf-lua was written for 0.5) and other oddities. Granted if I were to write this part from scratch I’d clean up (as described) but there would still be no way to avoid all the hard coded use-cases (try to imagine the F5/F6 preview rotate functionality).

That said, it is working pretty much perfectly :)

EDIT: it’s been “bloody” to get to this point, read this comment for example, so many edge case can affect the layout and have to be accounted for: https://github.com/ibhagwan/fzf-lua/blob/054c312b1cc327be68045ffc4926133a60ff9b82/lua/fzf-lua/win.lua#L443-L447

@ibhagwan bad english (it autocorrect my "optionated" word). I mean it already has a lot of options to choose and set, and i do think that majority of it is never touched by any user so it just complicate codebase. But maybe it's just opinion of the user who do like simplicity over complexity.

I get what you are trying to say but the reason is flawed, fzf-lua code complexity doesn't matter for end users anyway. Dev ? yes

Also overkill ? Nah, one more generic config option, like title_align or something. In the end i just wanted center text, nothing serious, haha. I will go away for now.

That said, it is working pretty much perfectly :)

True, its a treat to watch flex layout working its charm when window is resized.

By the way, i centered the text, looks beautiful. Also attached screenshots for various ridiculous sizes and positions.

Would you be open to a pr ? I will add the config option, obviously.

This one is absurd, i know.

By the way, i centered the text, looks beautiful. Also attached screenshots for various ridiculous sizes and positions.

Looks nice if centered is your thing :)

Would you be open to a pr ? I will add the config option, obviously.

Feel free, though I think at this point I’d rather rewrite the window class and have the title and it’s alignment part of the class so the option setting would probably be slightly different.

Feel free, though I think at this point I’d rather rewrite the window class and have the title and it’s alignment part of the class so the option setting would probably be slightly different.

Done https://github.com/ibhagwan/fzf-lua/pull/503

Is there a way to replace quickfix window in vim with fzf? I like the floating window of fzf for lsp, but I prefer jumping to definition immediately when only one is available.

Is there a way to replace quickfix window in vim with fzf? I like the floating window of fzf for lsp, but I prefer jumping to definition immediately when only one is available.

Have you seen https://github.com/ibhagwan/fzf-lua/wiki#lsp-single-result

Oh, no, I obviously have not. Thank you!

But still, it doesn't work for me when I try to put it in setup:

require'fzf-lua'.setup {
  lsp_declarations = {jump_to_single_result = true},
}

Also, shouldn't this work with only setting this for lsp_locations as that is the function resolving all of the lsp file jumps.

Edit: Sorry, I thought I looked through the wiki thoroughly, but probably not. Found the lsp table in the defaults and there it worked.

Sorry, I thought I looked through the wiki thoroughly, but probably not. Found the lsp table in the defaults and there it worked.

Not your fault, there are many options, some obscure and semi undocumented, one can easily get lost :)

What about adding support for LSP reference options? includeDeclaration=false for example.

What about adding support for LSP reference options? includeDeclaration=false for example.

You can already achieve somewhat similar result with ignore_current_line option.

@ibhagwan wanted to share a strange behaviour i noticed, not sure if worth an improvement, all file related pickers at the moment kind of trigger un intentionally some Buf* or other similar events twice. That happens i assume because when you select within an fzf picker, say from oldfiles, the picker first closes, focuses the old window, BufEnter triggers, and then the :explore on the old file selected from the picker is run in the same window, triggering the actual BufEnter for the selected entry, would be nice if we could get the target window handle, before opening fzf, and open the file in that window before focus is swapped from fzf to that window, to avoid the double events (one for the new file, which is desired, and one for the old one which is happening due to fzf closing swapping focus to the window before :explore)

I am sure which other events might also get the same treatment, not sure how telescope handles that, but this behaviour could confuse people who rely on such types of events.

@ibhagwan wanted to share a strange behaviour i noticed, not sure if worth an improvement, all file related pickers at the moment kind of trigger un intentionally some Buf* or other similar events twice. That happens i assume because when you select within an fzf picker, say from oldfiles, the picker first closes, focuses the old window, BufEnter triggers, and then the :explore on the old file selected from the picker is run in the same window, triggering the actual BufEnter for the selected entry, would be nice if we could get the target window handle, before opening fzf, and open the file in that window before focus is swapped from fzf to that window, to avoid the double events (one for the new file, which is desired, and one for the old one which is happening due to fzf closing swapping focus to the window before :explore)

I am sure which other events might also get the same treatment, not sure how telescope handles that, but this behaviour could confuse people who rely on such types of events.

Your analysis is correct, for an action to be executed FzfLua first has to close the terminal window which triggers the first BufEnter as we return to the original window and then open the selected buffer for edit which triggers another event.

As for the suggested fix this would be a bit of a change in the logic to execute the action before the FzfLua window closes, while possible, it is a bit of headache which is going to take at least a day of testing and trying to understand what else might be affected due to this change, I’ll take a look at the code later and see if it’s a quick and easy change bit otherwise I’m leaning towards a “not worth the effort for the minor inconvenience”.

Thanks, another small unrelated to my previous comment issue i noticed is related to lsp_workspace_diagnostics, looking at the docs and implementation, it does seem to accept a cwd to filter the diagnostics but passing it a cwd does not seem to affect the results. Tried opening two different lua projects in the same nvim instance to test it out (with two separate work dirs)

Thanks, another small unrelated to my previous comment issue i noticed is related to lsp_workspace_diagnostics, looking at the docs and implementation, it does seem to accept a cwd to filter the diagnostics but passing it a cwd does not seem to affect the results. Tried opening two different lua projects in the same nvim instance to test it out (with two separate work dirs)

https://github.com/ibhagwan/fzf-lua/commit/66a84a6c1e208e1789f7bff1a6fdc76593a90b5f - should work now.

@ibhagwan wanted to share a strange behaviour i noticed, not sure if worth an improvement, all file related pickers at the moment kind of trigger un intentionally some Buf* or other similar events twice. That happens i assume because when you select within an fzf picker, say from oldfiles, the picker first closes, focuses the old window, BufEnter triggers, and then the :explore on the old file selected from the picker is run in the same window, triggering the actual BufEnter for the selected entry, would be nice if we could get the target window handle, before opening fzf, and open the file in that window before focus is swapped from fzf to that window, to avoid the double events (one for the new file, which is desired, and one for the old one which is happening due to fzf closing swapping focus to the window before :explore)

I am sure which other events might also get the same treatment, not sure how telescope handles that, but this behaviour could confuse people who rely on such types of events.

@asmodeus812, turns out this doesn't require actions logic modifications - https://github.com/ibhagwan/fzf-lua/commit/2f3df3891e26f8dd2d758bb5ab7267c1ee6dcf4c:

https://github.com/ibhagwan/fzf-lua/blob/2f3df3891e26f8dd2d758bb5ab7267c1ee6dcf4c/lua/fzf-lua/utils.lua#L663-L669

@asmodeus812, note that https://github.com/ibhagwan/fzf-lua/commit/e6d71ad8eacce05e43522ee60e82d385af82dfd4 reverts the effects of the last commit, as expected something like that has some unintended consequences such as updating statusline plugins, since now events don't fire the some statusline updates don't trigger, give this has worked until now with no complaints I'm going to leave it like this (firing the BufEnter) until a better solution is found.

What about adding support for LSP reference options? includeDeclaration=false for example.

@abenz1267, FYI, althought ignore_current_line provides a similar solution I added support for includeDecleration in the actual LSP request context in https://github.com/ibhagwan/fzf-lua/commit/a81d18ee591635ce537bfa045ed1edf7dbe30cf3, you can now run :FzfLua lsp_references includeDeclaration=false.

@monkoose, since the only outstanding feature from this issue is "Title for grep/file commands" and I'm planning it as part of a much bigger window/popup class refactor I'm going to close this issue for now as it's long lost its course, once I get to it (can't promise when) I surely won't forget to add a title option for every window :-)