It seems that `vim.fn.expand('%')` will return `{bufnr}/{file_path}` instead of `{file_path}` from the preview buffer

[nyngwang]

Description

Context

In nvim-treesitter there is an option(it's a key of a table) is_supported for a module, which is used to determine whether or not the module should be enabled on a given buffer.

Problem

In is_supported, I need to make use of vim.fn.expand('%') to get the name of the file to be opened. So I tried to print() it, and I realized that the output looks different after I run any fzf-lua command with a preview window(I guess treesitter was trying to parse the preview buffer), e.g.

22:34:44 msg_show 196/bfd.h
22:34:44 msg_show 199/cmp-codeium.md
22:34:44 msg_show 202/hello.go
22:34:45 msg_show 205/lazy-lock.json

So I assume the format is {bufnr}/{file_path}. This increases the complexity of getting the path of the file:

-- to get the `{file_path}` only
(vim.fn.expand('%'):gsub('^%d*/', ''))

Is this by design? If so, am I correct to say that the format is {bufnr}/{file_path}? I'm afraid that my assumption might be wrong, then my further usages of {file_path}, e.g. some APIs will return nil if the file path is invalid(apparently I don't have folders {bufnr} under the current path), will all be wrong.

Thanks for your reading.

[ibhagwan]

FzfLua does not modify the behavior of expand nor have I seen this behavior anywhere else, I don’t think this is related to fzf-lua.

I just realized what you meant, yes, this is by design, this is done in order to set the preview buffer name/file type so it can be properly highlighted but not conflict with any other existing buffer, this is the most efficient way to have proper syntax highlighting and is not subject to change.

Btw, the issue here is not with expand, this is actually the (temporary) buffer name.

Relevant code: https://github.com/ibhagwan/fzf-lua/blob/292de730ebbd3834e87f864c8c4115dc1035db37/lua/fzf-lua/previewer/builtin.lua#L671-L675

[ibhagwan]

If you need the selected entry why don’t you use get_info? See https://github.com/ibhagwan/fzf-lua/issues/537#issuecomment-1272418720

[nyngwang]

[...] so it can be properly highlighted but not conflict with any other existing buffer, [...]

Clever idea! I didn't consider this part. Thanks for your explanation :)

Btw, the issue here is not with expand, this is actually the (temporary) buffer name.

But during my testing, the only line I used to print is this: (maybe the underlying code would pick buffer name for expansion?)

is_supported = function ()
  print(vim.fn.expand('%'))
  -- other code omitted.
end

This is my config of nvim-treesitter if you want to test:

require('nvim-treesitter.configs').setup {
  auto_install = true,
  ignore_install = { 'c', 'help', 'vim', 'lua', 'phpdoc', 'd', 'comment' },
  highlight = {
    enable = true,
    language_tree = true,
    is_supported = function ()
      -- Since `ibhagwan/fzf-lua` returns `bufnr/path` like `117/lua/plugins/colors.lua`.
      local cur_path = (vim.fn.expand('%'):gsub('^%d+/', ''))
      print(cur_path)
      if cur_path:match('term://')
        or vim.fn.getfsize(cur_path) > 1024 * 1024 -- file size > 1 MB.
        or vim.fn.strwidth(vim.fn.getline('.')) > 300 -- width > 300 chars.
      then return false end
      return true
    end
  },
}

If you need the selected entry why don’t you use get_info?

If I use fzf-lua's get_info to get the buffer name, then nvim-treesitter will only work with these preview buffers but not the other buffers.

[ibhagwan]

But during my testing, the only line I used to print is this: (maybe the underlying code would pick buffer name for expansion?)

When you call expand with % you’re asking for the current buffer name, this is the same as calling vim.api.nvim_get_current_buffer(), since the buffer name is prepended with the buffer number the result is what you experience, this is the actual name of the temporary preview buffer.

[nyngwang]

Okay. I will keep using this (vim.fn.expand('%'):gsub('^%d+/', '')) until it might be changed in the future. Closing...