Custom filetype with mini.icons

[ibhagwan]

I use 'mini.icons' and when modify filetype config as in the following example, the corresponding file's icon displayed incorrectly in fzf-lua window. Is there some workaround maybe?

vim.filetype.add({
  filename = {
    ["somefile"] = "lua",
  },
})

Originally posted by @nowaylifer in https://github.com/ibhagwan/fzf-lua/discussions/1497

[ibhagwan]

@nowaylifer, unfortunately I don't think this can be supported with current architecture, for performance reasosn, fzf-lua uses an external process to "iconify" the files which uses a cached versions of mini.icons internal structures.

The issue here is that the custom filetypes from vim.filetype.add don't get through to the external process which then caches the custom filenames with the default icon.

The only way to work around (which isn't really a solution) is to run fzf-lua on the main neovim thread before anything else which will then cache the custom filetypes, try running this inside the folder with the custom filetypes:

:FzfLua files file_icons=mini multiprocess=false

This will cache the custom filetype/filename (assuming it was enumerated inside the direcory) after which you can use multiprocess (the default).

While I can technically query the main thread's filetypes for unknown files as fallback this would negate the external process performance gains (and much worse).

Maybe I'm missing something but I couldn't find a way to enumerate all custom filenames/filetypes, as there's no vim.filetype.list equivalent.

Perhaps @echasnovski will have an idea how to solve this as := _G.MiniIcons.list("file") currently doesn't return the custom filename/filetype and relies on vim.filetype.detect to do the resolving and cache the result.

[echasnovski]

Yes indeed, if filetype detection is set up with vim.filetype.add({ filename = { somefile = 'lua' } }), then MiniIcons.get('file', 'somefile') will work (as it falls back to vim.filetype.match() directly to infer filetype and eventually return the same output as MiniIcons.get('filetype', 'lua')), but 'fzf-lua' will not (for reasons extensively stated in previous comment).

The way to work around it is to also explicitly set up 'mini.icons' to be aware of special 'somefile' file name. This can be done like this:

require('mini.icons').setup({
  file = {
    -- Use output of `MiniIcons.get('filetype', 'lua')`
    somefile = { glyph = '󰢱', hl = 'MiniIconsAzure' },
  },
})

Now 'somefile' will be present in the output of MiniIcons.list('file') and 'fzf-lua' should pick it up.

[ibhagwan]

Yes indeed, if filetype detection is set up with vim.filetype.add({ filename = { somefile = 'lua' } }), then MiniIcons.get('file', 'somefile') will work (as it falls back to vim.filetype.match() directly to infer filetype and eventually return the same output as MiniIcons.get('filetype', 'lua')), but 'fzf-lua' will not (for reasons extensively stated in previous comment).

The way to work around it is to also explicitly set up 'mini.icons' to be aware of special 'somefile' file name. This can be done like this:

require('mini.icons').setup({
  file = {
    -- Use output of `MiniIcons.get('filetype', 'lua')`
    somefile = { glyph = '󰢱', hl = 'MiniIconsAzure' },
  },
})

Now 'somefile' will be present in the output of MiniIcons.list('file') and 'fzf-lua' should pick it up.

Elegant and easy solution, Ty @echasnovski!

FYI @dpetka2001.

[dpetka2001]

In my case, I had to use extension instead of file as it seems to only resolve explicit filenames. I tried with *.lua to see if it accepts wildcards, but did not work. I can now skip invoking buffers first and use directly my custom function.

Thank you so much both of you for your help and explanations and insight you provide :smile:

[echasnovski]

I tried with *.lua to see if it accepts wildcards, but did not work.

No wildcards for 'file' category. If you have extension filetype match, then yes, 'extension' category should be used.