:Telescope fzf yields E5108: Error executing lua ...ck/packer/start/telescope.nvim/lua/telescope/command.lua:184: attempt to call a nil value

[elmarsto]

After successful :PackerSync and restart, I still cannot run :Telescope fzf. I get the following error:

E5108: Error executing lua ...ck/packer/start/telescope.nvim/lua/telescope/command.lua:184: attempt to call a nil value 

This is the relevant part of my config (packer-based, obvs)

    use {
      "nvim-telescope/telescope.nvim",
      requires = {
        "sharkdp/fd",
        "nvim-lua/plenary.nvim",
        {"nvim-telescope/telescope-packer.nvim", requires = "wbthomason/packer.nvim"},
        {"nvim-telescope/telescope-fzf-native.nvim", run = "make"}
      },
      config = function()
        local tscope = require("telescope")
        tscope.setup {}
        tscope.load_extension "packer"
        tscope.load_extension "fzf"
      end
    }

[elmarsto]

further context:

[fdschmidt93]

To clarify, :Telescope fzf is not a command.

telescope-fzf-native is an optional dependency for telescope to make use of a fast fzf-style sorter to builtin telescope pickers. I'd have to check the code once more, but if I recall correctly it works by linking the telescope config for fuzzy sorter against telescope-fzf-native. So, once installed, almost all telescope builtins (the main exception being live_grep) will use telescope-fzf-native as a sorting algo for faster sorting and the nice syntax as per the project README. If you are wondering about live_grep, it's, simply put, a front-end to ripgrep.

"sharkdp/fd",

fd is an optional dependency to be installed on your system via your system package manager or by downloading the binary or compiling from source, rather than managing it via packer.

I hope that helps, let me know in case you have further questions :)

[elmarsto]

Ah! Thank you. Interestingly, 'fzf' is offered as a tab-completion on :Telescope if and only if this package is installed.

Given that what you've said above indicates that this command is not present, I wonder (a) where the completion is coming from and (b) how to deactivate it, both on my install, and everyone else's?

I'm pretty new to what I've taken to calling the 'new neovim' -- I've been an nvim user for a couple of years, but didn't scratch the surface until I began running -nightly, installed a bunch of nvim-only plugins like Telescope, got tree sitter and LSP going, etc.

Now it feels like I've pulled the sword from the stone. Damn, this is cool.

The sword, however, has a few sharp edges, and not always on the blade part ;D

[elmarsto]

If it helps track down the problem, here is my (rather lengthy and in need of refactoring) current lua config.

https://github.com/elmarsto/nvim-config/blob/main/lattice.lua

Apologies for the mess, file length, and/or general naiveté :D

Mumbled excuses: I'd been managing nvim with nix and home-manager up until recently, hence the mess; I just moved.

(If you're interested: Nix still generates the file named lattice_local.lua, which gets its fancy /nix/store/.../ absolute paths for binaries, which is kind of cool, but the built-in home-manager neovim config module just wasn't keeping up with Packer, and lengthened my edit/:PackerSync/debug cycle considerably, having to home-manager switch every time I tweaked it. (This is the one bad thing about nix: a change to any one file occasions a rebuild and, unless you're rocking a local copy of the nix channels, you are going to want to be Internet-connected.))

My new solution works but I just put it together the last week or so, and I'm not finished unpacking.

[fdschmidt93]

Completion for vim commands are auto-generated. Here, it's just that telescope-fzf-native is the odd one out across telescope extensions; for most other that would be meaningful as to consistently with built-in experience call the picker(s) of the extension as implemented here (eg :Telescope frecency for the popular telescope-frecency). Consequently, I'm afraid deactivating will be rather hard.

I realize landing on the telescope-fzf-native README lacking more telescope-context can be a bit confusing. Our developers-guide is a great start to get more familiar with what and how telescope can do some of the things.

The sword, however, has a few sharp edges, and not always on the blade part ;D

Telescope can do much more; much more to the degree it's difficult to document and keep track of all of it :sweat_smile:

(If you're interested: Nix still generates the file named lattice_local.lua, which gets its fancy /nix/store/.../ absolute paths for binaries, which is kind of cool, but the built-in home-manager neovim config module just wasn't keeping up with Packer, and lengthened my edit/:PackerSync/debug cycle considerably, having to home-manager switch every time I tweaked it. (This is the one bad thing about nix: a change to any one file occasions a rebuild and, unless you're rocking a local copy of the nix channels, you are going to want to be Internet-connected.))

Nix would be my personal next step after Arch I suppose; maybe next time something breaks and I have some time getting into it :) E: Ah, If I understand correctly, fd there makes a lot more sense I suppose :)

[Conni2461]

I dont get this issue. So i am closing this because i think the first answer handled by fdschmidt is sufficient. Everything else is just offtopic.

fzf-native changes a config value to a custom function, thats all it does. The custom function returns a table (basically a instance of a class that implements a Interface). And it has one important function sort which gets the current prompt (input) and one entry (it will be called for all entries in the result). It will then calculate a score and return this score. fzf-native just implements the fzf algorithm for telescope which is faster than the default implementation in telescope (because its written in core) and has more features, see readme. You can try this in ANY picker (besides live_grep), by just typing search_value1 | search_value2, etc...