filename_first renders path not correctly for git_status

[LinoWhy]

Description

With the following config

path_display = { filename_first = { reverse_directories = false } },

Filename is shown first, directroies are shown with grey color.

But the directroies are not in grey with git_status:

Neovim version

NVIM v0.10.0-dev-3122+ga0a189a8e
Build type: RelWithDebInfo
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info

Operating system and version

Ubunut 22.04

Telescope version / branch / rev

master

checkhealth telescope

telescope: require("telescope.health").check()

Checking for required plugins ~
- OK plenary installed.
- WARNING nvim-treesitter not found. (Required for `:Telescope treesitter`.)

Checking external dependencies ~
- OK rg: found ripgrep 14.1.0 (rev 4aa92c5b6e)
- OK fd: found fd 10.1.0

===== Installed extensions ===== ~

Steps to reproduce

1. open nvim with mini config
2. Type ":Telescope git_status"

Expected behavior

No response

Actual behavior

Directories in telescope git_status is not shown in grey.

Minimal config

local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  {
    "nvim-telescope/telescope.nvim",
    dependencies = { "nvim-lua/plenary.nvim" },
    opts = {
      defaults = {
        layout_strategy = "vertical",
        path_display = { filename_first = { reverse_directories = false } },
      },
    },
  },
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

[jamestrew]

Thanks for reporting - I can reproduce this as well.
I'll try to get around to this when I get a chance. Also happy to help someone else they're interested in taking this.

[jamestrew]

Oh ok so this is actually a known limitation of the filename_first path_display option at the moment. It doesn't work with all pickers (specifically those that use entry_display.create as part of the entry making process).
#3010 (comment)

This is definitely something I want to address sooner rather than later but needs some consideration.

[jamestrew]

Ok fixing the entry_display.create compatibility was actually pretty trivial.
Let me know if that above PR helps.

[LinoWhy]

Ok fixing the entry_display.create compatibility was actually pretty trivial. Let me know if that above PR helps.

@jamestrew LGTM, thanks!

[eddiezane]

Thanks for reporting this and the fix! I just came across this while pulling out hair for the past week trying to figure out why filename_first wasn't working with find_files. I had just ruled out it was something on my end 😅. Appreicate y'all.