I recently started using fzf-lua shortly before you refactored this plugin to use register_ui_select exclusively. Since adding in the configuration to use require('fzf-lua').register_ui_select(...) which is now recommended, when trying to setup a custom handler via dressing using get_config = function (d) if d.kind == '...' then ... end I find that the ui.select function is completely overtaken by fzf-lua. So whatever the custom behaviour of my get_config for select in dressing. Once fzf-lua is present with it's registration function it completely takes over.
This might be by design on your part to allow users of that plugin defer entirely to it, but for me one of the key advantages of dressing is that I can route how different things are handled. I'm wondering if it's possible to still have dressing in charge overall but only deferring to fzf-lua if I haven't set some other custom handler.
I'm not sure if maybe this will require some sort of work on both sides though since perhaps (haven't checked) the fzf-lua implementation just directly overrides vim.ui.select but my thinking re. a solution would be a way to check if the value of vim.ui.select ~= dressing_override_fn in which case it stores the old overrider i.e. fzf-lua's one and tries to handle it but if there is not custom handler then it uses that as the fallback.
This might be nowhere near a good solution just some guesstimations based on not having looked at either implementation in detail.
I've undeprecated the fzf_lua config. Previously I think there was no way to pass in the config options to their implementation of ui.select, but now there is so we can gracefully call into it
Hi @stevearc,
I recently started using
fzf-lua
shortly before you refactored this plugin to useregister_ui_select
exclusively. Since adding in the configuration to userequire('fzf-lua').register_ui_select(...)
which is now recommended, when trying to setup a custom handler via dressing usingget_config = function (d) if d.kind == '...' then ... end
I find that theui.select
function is completely overtaken byfzf-lua
. So whatever the custom behaviour of myget_config
forselect
in dressing. Oncefzf-lua
is present with it's registration function it completely takes over.This might be by design on your part to allow users of that plugin defer entirely to it, but for me one of the key advantages of dressing is that I can route how different things are handled. I'm wondering if it's possible to still have dressing in charge overall but only deferring to
fzf-lua
if I haven't set some other custom handler.I'm not sure if maybe this will require some sort of work on both sides though since perhaps (haven't checked) the
fzf-lua
implementation just directly overridesvim.ui.select
but my thinking re. a solution would be a way to check if the value ofvim.ui.select ~= dressing_override_fn
in which case it stores the old overrider i.e. fzf-lua's one and tries to handle it but if there is not custom handler then it uses that as the fallback.This might be nowhere near a good solution just some guesstimations based on not having looked at either implementation in detail.