Support fzf-lua as select-node dialog

[broken-pen]

Hi! For the past few weeks, I've been privately experimenting with a fork of Org-Roam where the select-node dialog has been replaced with fzf-lua's fuzzy-finder interface.

I've also added a config ui.select.annotation that mimicks the option org-roam-node-annotation-function of Emacs Org-Roam. It differs from the previously introduced custom label formatting by using different highlight groups:

• the built-in select-node interface uses the highlight groups PmenuExtra and PmenuExtraSel;
• the fzf-lua interface always highlights annotations in gray right now.

I've marked this PR as a WIP for now because there are several design decisions involved that I'd like your input on before actually considering merging it. Please consider the current version only a draft 🙂

A few design questions that come to my mind:

• Should the code live in org-roam.core.ui and org-roam.ui or would it better fit into org-roam.extensions?
• Similar for the configs: As they are right now or better under extensions?
• Are the "annotations" even a feature you want to support in the first place?
• FZF-related options (window style, etc.) right now can only be set through fzf-lua's setup() call. Would it make sense to provide a config entry point in org-roam?
• I've managed to make the transfer of display items from nvim to fzf fully asynchronous. This ended up getting very messy because we use Orgmode's OrgPromise API whereas fzf-lua uses coroutine. I'm not sure this is worth the trouble.
• Default options for the FZF dialog should be considered; we can make it look a lot more like the built-in select dialog by default, if we want.

And once all this is settled, we'll have to discuss various coding decisions obviously 😅

Feel free to take your time and as always, thank you for maintaining this awesome plugin!

[chipsenkbeil]

Hey there, have skimmed the PR, but haven't spent time to read through it more closely.

My first thought is why this needs to be directly incorporated into this plugin instead of as a standalone plugin. Would it make more sense to incorporate features you need like the annotation function directly in this plugin, and then add the alternative select UI as a plugin that you maintain?

My concern is that adding a dependency means that:

1. I need to continually check if my plugin is compatible with it. If that plugin breaks compatibility upstream, I have to fix my plugin as a result.
2. Because of the first issue, I'd need to mark what version of that fzf plugin that org-roam is compatible with, and start tagging based on both nvim-orgmode and the fzf plugin.
3. This opens the door to adding more dependencies outside of nvim-orgmode, which is the only one I'd prefer to have to reduce maintenance burden.

So what are your thoughts about splitting this out into the changes you need to support fzf-lua within this plugin, and then a separate plugin that you could maintain that offers the fzf integration?

[broken-pen]

Hi, your concerns are perfectly reasonable! It's been a while, but I think my reason to add this into org-roam because I need to override part of the API to switch over to the fzf-based dialog. (org-roam.ui.select_node to be precise) Doing this across plugins is a little sketchier than within a plugin.

For now I've reset the PR to exclude the last commit and keeping it in a separate branch.

[chipsenkbeil]

Hi, your concerns are perfectly reasonable! It's been a while, but I think my reason to add this into org-roam because I need to override part of the API to switch over to the fzf-based dialog. (org-roam.ui.select_node to be precise) Doing this across plugins is a little sketchier than within a plugin.

If we can come up with a way to make that less sketchy and more officially supported (as a pluggable api), I'm all for it :)

[seflue]

I would also prefer an API, where plugins can be plugged in. A configurable function for example, which I can implement to call my own picker.
I am currently working on a big overhaul of Telescope-Orgmode, so it will support multiple picker frameworks with the next release. I currently support Telescope and Snacks.picker on my dev branch, but fzf.lua is also planned.

A node picker for org-roam was always on my list of features, so it is probably better to integrate it in Telescope-Orgmode than creating a hard-tailored solution directly in org-roam.