Telescope (randomly) won't match symlinks

[jrwrigh]

Description

Telescope isn't matching symlinks for some reason. I honestly don't know what else to say. I had it working a few days ago (at least I think I did), accidentally deleted part of my configuration for neovim, and upon remaking it, telescope doesn't match symlinks anymore. I can reproduce it with the minimal config below.

Neovim version

NVIM v0.7.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Operating system and version

Manjaro Linux

checkhealth telescope

telescope: require("telescope.health").check()
========================================================================
## Checking for required plugins
  - OK: plenary installed.
  - OK: nvim-treesitter installed.

## Checking external dependencies
  - OK: rg: found ripgrep 13.0.0
  - OK: fd: found fd 8.4.0

## ===== Installed extensions =====

Steps to reproduce

Go to a directory with symlinks and try to match it (ie. type the name of the file). Example:

$ ls **/*
after/syntax/dosini.vim    coc-settings.json     init.lua      lua/mappings.lua  lua/setup/cmp.lua         lua/setup/gitsigns.lua          lua/setup/lsp.lua      lua/setup/telescope.lua   plugin/packer_compiled.lua  vim_folding.vim
after/syntax/markdown.vim  coc_settings.vim      init.lua.old  lua/options.lua   lua/setup/comment.lua     lua/setup/indent_blankline.lua  lua/setup/lualine.lua  lua/setup/treesitter.lua  spell/en.utf-8.add
after/syntax/matlab.vim    i3config_folding.vim  init.vim.old  lua/plugins.lua   lua/setup/easy_align.lua  lua/setup/lsp-installer.lua     lua/setup/monokai.lua  ncm2_settings.vim         spell/en.utf-8.add.spl

running :lua require('telescope.builtin').find_files() in neovim results in:

./spell/en.utf-8.add.spl    
./spell/en.utf-8.add        
./plugin/packer_compiled.lua
./init.lua.old

which are the only non-symlinked files in the entire directory.

Expected behavior

Match symlinks

Actual behavior

Doesn't match symlinks

Minimal config

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
  require('packer').startup {
    {
      'wbthomason/packer.nvim',
      {
        'nvim-telescope/telescope.nvim',
        requires = {
          'nvim-lua/plenary.nvim',
          { 'nvim-telescope/telescope-fzf-native.nvim', run = 'make' },
        },
      },
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
      display = { non_interactive = true },
    },
  }
end
_G.load_config = function()
  require('telescope').setup()
  require('telescope').load_extension('fzf')
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing Telescope and dependencies.")
  vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]

[Conni2461]

fd is installed so you end up using that. The default command is fd --type f try it in your directory and you will find out that those files aren't listed either. We have a shorthand to follow links Telescope find_files follow=true. Also the find command doesn't follow symlinks.

You could have found that when reading :help telescope.builtin.find_files. Hope that helps. This issue is resolved imo

[jrwrigh]

Yep, that worked. I read that section of the help document (and even found issue #394) and misinterpreted "follow symlinks" as "recurse into symlinked directories" rather than "allow displaying of symlink files". Specifically this comment/description of their problem threw me off, as my situation is of the files themselves being symlinks rather than a symlinked directory.