cannot work with telescope 0.1.2 on Windows

[bo-wu]

I use lazyvim to manage plugins, and add telescope-fzf-native.nvim in the config file as described in Readme, like this

  { 
    'nvim-telescope/telescope-fzf-native.nvim', build = 'make', 
    config = function()
      require("telescope").load_extension("fzf")
    end,
  },

the lazyvim manage to download and compile the plugin. However, when I use telescope to search file or symbols, the nvim will freeze or crash without any information.

[qgates]

@bo-wu Are you using cygwin64 to provide the gcc toolchain for building the plugin? If so, some hacking is necessary to get a binary dll compatible with win x64.

Using gcc toolchain from cygwin builds an incompatible dll, causing the crash. You need to use the mingw64-x86_64 variants of these tools. You will then also either need to modify the makefile to call run x86_64-w64-mingw32-gcc instead of gcc, or rename the compiler to gcc so it will work with the makefile.

There should probably be some improvements to this for Windows users, some OS detection in the makefile, better still a pre-built binary since it's uncommon for sources to be built on Windows hosts.

[xarthurx]

Is it possible to use VS-build instead of make? building tool chain on Windows is actually quite complete now.

[Conni2461]

no its not possible, we offer cmake as an alternative to build this project (and we suggest this on windows), it can be consumed by vs-build, so i think this is sufficient. I have 0 interest in adding a third build system to this project.

I'd rather add some kind of process where we, build this project in CI and offer the possibility that people can easily download the binary using an installer function #93

[xarthurx]

CMake is not a building tool but a pre-build tool? with CMake, you still need some build tool like MS-build on Windows platform.

Actually there're pre-build and installable fzf executables on Windows, either through winget or scoop (Windows Package Manager).

[Conni2461]

CMake is not a building tool but a pre-build tool

yeah but you can use cmake to generate ms-build tools. None the less its some build tool like thing and i dont plan to add a third, because adding more stuff always means that you also have to maintain that stuff and its really hard to maintain something that you dont use and you dont even have access to that. With cmake i dont have that problems thats why we added it.

So no i'll never add a windows/platform specific build too

Actually there're pre-build and installable fzf executables on Windows

yeah but this project does not use the fzf executable, it reimplements the algorithm in c so it can be used in lua, e.g.

[xarthurx]

Understood.

Only one last comment is, with the current config, Windows users will have errors like this:

if they don't have make or cygwin installed -- this should be properly dealt with.
Installing cygwin just for a vim-plugin is a bit too much a requirement.

[Conni2461]

this should be properly dealt with.

how should this be dealt with? The error message says exactly whats the problem. The REQUIRED dll cant be loaded. Its a requirement we cant relax. The whole plugin lies in the end in that resulting dll. And failing silently is even worse because then you dont even know that the plugin isn't loading and because of that the supported features aren't present.

Installing cygwin just for a vim-plugin is a bit too much a requirement.

thats why we are working on a downloader. I sadly can't change the fact that windows and microsoft priorities shipping spyware with the operating system but can't affort to ship a simple c compiler. Our solution for that is, like I already said a prebuild binaries and a downloader, but tbh its not really that high on my priority list. The windows support time of this plugin already exceeds the whole time it took me to write the actual plugin code ...

[xarthurx]

this should be properly dealt with.

how should this be dealt with? The error message says exactly whats the problem. The REQUIRED dll cant be loaded. Its a requirement we cant relax. The whole plugin lies in the end in that resulting dll. And failing silently is even worse because then you dont even know that the plugin isn't loading and because of that the supported features aren't present.

Installing cygwin just for a vim-plugin is a bit too much a requirement.

thats why we are working on a downloader. I sadly can't change the fact that windows and microsoft priorities shipping spyware with the operating system but can't affort to ship a simple c compiler. Our solution for that is, like I already said a prebuild binaries and a downloader, but tbh its not really that high on my priority list. The windows support time of this plugin already exceeds the whole time it took me to write the actual plugin code ...

Totally understood. The Windows support approach looks fine for me.
Just FYI, after some investigation, I found out that with the scoop package management system on Windows, one can directly install make, without installing UNIX env like cygwin or mingw.

[hxshandle]

@xarthurx I used scoop to install the make, but after that, no help is any other action need to helps recompile the plugin

[AQian0]

@hxshandle

I'm having the same problem as you.
I think it might have something to do with the scoop, such as the way the links are linked and so on.
Because when I installed it by Lazy.nvim, it didn't report an error in the compilation process.