Beta-testing 'mini.icons'

[echasnovski]

Please leave your feedback about new mini.icons module here. Feel free to either add new comment or positively upvote existing one.

Some things I am interested to find out (obviously, besides bugs):

• Does it work well out of the box with your existing setup? Like:

  • Are icons rendered well? If not, there might be a terminal emulator and/or font issue, see Dependencies section.
  • Are colors for icons that are important for you chosen reasonably?

• Do you have any suggestion about changing some icon's glyph and/or highlight group? I'd like to warn right away about what probably won't be done:

  • Adding narrowly scoped programming language-related icons. For example: special treatment of d.ts extension.
  • Changing glyph which is explicitly designed for where it is used. For example: almost whole "lsp" category.

  What I am open for and welcome:

  • Adjusting filetype glyph which was added from a set of "generic" nf-md-alpha-* icons. For example, like this. It needs a reasonable suggestion, though.
  • Adding new filetype icon data for plugins, if they have workflow which allows making buffer with that filetype current (like opening floating window or split with the buffer). Most of popular ones are already added, but I might have missed some.

• Is configuration intuitive enough?

• Are default values of settings convenient for you?

• Is documentation and examples clear enough?

Thanks!

[SebasF1349]

Great new module! I've been playing with it and doing some comparations with devicons and I found out that icons are missing in files with "double" extensions. Specially in typescript files (javascript is working ok). I can't think of any other language I use that have those.

Here is a pic from telescope (that works great with the mocking).

Still not sure about some colors, will have to think about it as I'm not sure if I think they are wrong or it's just that I have to get use to them. Will post later about it.

[folke]

First of all, thank you for this great new module!

Just wanted to let you know it currently doesn't work with fzf-lua.
It trips at the line https://github.com/ibhagwan/fzf-lua/blob/3b91c1a471160bd8620bdca8f18743d954994daa/lua/fzf-lua/devicons.lua#L81

[folke]

You should probably also change this line https://github.com/echasnovski/mini.icons/blob/b5e40acb2f0de7127bbcf026f3a0a55189a428a4/lua/mini/icons.lua#L427

When lua starts loading a module, it changes the value in package.loaded to true.
So better to check for type == "table".

[folke]

Work-around to make it work on fzf-lua

  {
    "echasnovski/mini.icons",
    lazy = true,
    opts = {},
    init = function()
      package.preload["nvim-web-devicons"] = function()
        local Icons = require("mini.icons")
        local ret = {}
        package.loaded["nvim-web-devicons"] = ret
        Icons.mock_nvim_web_devicons()

        local function get(cat)
          local all = {}
          for _, name in ipairs(Icons.list(cat)) do
            local icon, color = ret.get_icon_color(cat == "file" and name, cat == "extension" and name)
            all[name] = { icon = icon, color = color }
          end
          return all
        end

        ret.get_icons_by_extension = function()
          return get("extension")
        end

        ret.get_icons_by_filename = function()
          return get("file")
        end

        ret.get_icons = function()
          return vim.tbl_extend("force", get("file"), get("extension"))
        end
        return ret
      end
    end,
  },

[echasnovski]

I found out that icons are missing in files with "double" extensions. Specially in typescript files (javascript is working ok). I can't think of any other language I use that have those.

@SebasF1349, thanks for the info! I am mostly positive that it is a typescript issue and not a "double extension" one. The problem here is that built-in vim.filetype.match() doesn't currently recognize 'ts' extension at all when used outside of some buffer context.

This means that telescope uses 'nvim-web-devicons' as get_icon(nil, 'd.ts', {}) instead of get_icon('app.d.ts', nil, {}) (i.e. supplies extension directly instead of file name.

You can check that 'mini.icons' does work correctly via :=MiniIcons.get('file', 'app.d.ts') which should return icon for typescript and "MiniIconsAzure" highlight group.

---

That said, during writing this I've got an idea of quite an easy fix for this in 'mini.icons'. Needs a bit more profiling but I think it will be solved.

---

So better to check for type == "table".

Work-around to make it work on fzf-lua

@folke, thanks for early beta-testing! I thought that mocking all get_icons_*() is meaningless as did not see the use for it. Seems like it will have to be done (at least so that you don't have to have it in LazyVim :) ). As it needs testing, I hope to do this tomorrow.

[folke]

About that ts thing, I had to include work-arounds for that in a number of my plugins.
The reason is that the ft detector tries to read the buffer (which is nil) and will error. That in turn will completely stop the ft check unfortunately.

The offending line in filetypes.lua is ts = detect_line1('<%?xml', 'xml', 'typescript').

Easiest way to fix is probably to always have a hidden scratch buffer ready that can be used as an argument.

And thanks for adding that extra stuff for nvim-web-devicons!

[echasnovski]

About that ts thing, I had to include work-arounds for that in a number of my plugins.
The reason is that the ft detector tries to read the buffer (which is nil) and will error. That in turn will completely stop the ft check unfortunately.

Yes, I figured this also some time ago. I planned to make fix this upstream by also recognizing contents properly instead of buf.

Easiest way to fix is probably to always have a hidden scratch buffer ready that can be used as an argument.

That was exactly what I thought about during writing that comment. Don't know why I didn't think about this sooner 🤦

[0x0003]

extension field doesn't seem to have any effect on dotfiles. E.g. :

require('mini.icons').setup({
  extension = {
    ['ghci'] = {
      glyph = '󰅩',
      hl = 'MiniIconsPurple'
    },
  }
})

Results in:

EDIT:
Scratch that, there's a file field for this case. Should've read the docs more thoroughly instead of skimming through 😕

[wroyca]

Thank for this! Testing it right now.

Are icons rendered well? If not, there might be a terminal emulator and/or font issue, see Dependencies section.

Note for those using Kitty; make sure to update your symbol_map here: https://sw.kovidgoyal.net/kitty/faq/#kitty-is-not-able-to-use-my-favorite-font

---

Changing glyph which is explicitly designed for where it is used. For example: almost whole "lsp" category.

Adjusting filetype glyph which was added from a set of "generic" nf-md-alpha-* icons. For example, like this. It needs a reasonable suggestion, though.

After using it today, here are some personal observations that might offer a different perspective;

Directory icons:

Enforcing "folder" type icons for all results in a mixed set. Personally, I believe that allowing exceptions for directories such as .github and .git contributes to better overall visual consistency:

- ['.git']      = { glyph = '', hl = 'MiniIconsOrange' },
- ['.github']   = { glyph = '', hl = 'MiniIconsAzure'  },
+ ['.git']      = { glyph = '󰊢', hl = 'MiniIconsOrange' },
+ ['.github']   = { glyph = '󰊤', hl = 'MiniIconsAzure'  },

Software:

The "executable" icon really stands out from the other "outline" icons in the same category. I think nf-oct-gear would fit better overall here (nf-md-cog-outline is a little too thick to blend well with the rest):

-exe  = { glyph = '󰒔', hl = 'MiniIconsGrey'  },
+exe  = { glyph = '', hl = 'MiniIconsGrey'  },

File icons:

The README icon stands out too much. Something like nf-md-file_document or nf-md-file_document_alert would, I believe, be more fitting:

-README = { glyph = '', hl = 'MiniIconsYellow' },
+README = { glyph = '󰈙', hl = 'MiniIconsYellow' },
-['README.md'] = { glyph = '', hl = 'MiniIconsYellow' },
+['README.md'] = { glyph = '󰈙', hl = 'MiniIconsYellow' },

Everything else:

Skipped, as it seems too specific to warrant any significant changes, and it already looks quite good to me as it is :)

---

Will continue to use it for the time being 🥳

[xarvex]

Thanks for yet another amazing module! I'm loving the style out of the box enough that I haven't really messed with any settings just yet. I have it working in oil currently. That being said, for some odd reason I am slightly different icons in Telescope (but they also aren't the same as nvim-web-devicons), I have attached a screenshot:

[wroyca]

Consider adding a Projects directory icon; the proposal is ongoing: https://gitlab.freedesktop.org/xdg/xdg-user-dirs/-/issues/3 but it'd be nice for those already using it :)

[echasnovski]

I've pushed some changes after early beta-testing.

---

There is now better fallback to vim.filetype.match(). @SebasF1349, this should fix the "missing ts icons in Telescope" problem (I've checked).

---

There is now fuller and (hopefully) smarter mocking in mock_nvim_web_devicons(). @folke, I think the whole LazyVim/LazyVim#3899 workarounds are now not needed. At least, I've tested and 'ibhagwan/fzf-lua' works with mocks. Although first class 'mini.icons' support should come to it eventually.

---

@wroyca, thanks for detailed feedback. Highly appreciated! Here are some thoughts:

• I have very strong opinion that directory icons should all resemble same "folder" icon. This is the main way to differentiate files and directories. Especially considering that '.git' can be both file and directory.
• I understand the point of "README icon stands out too much", but standing out was the intention here. Especially as it is shown in demo, it will be hard to convince me to change it :)
• Agree about "exe" icon. I replaced it with "windows" icon (as I saw LazyGit uses it) with red color (that draws attention and is not blue used in "os").
• I'll gladly add "Projects" directory after it is made official. I don't think it is used universally enough to be included now.

---

@xarvex, the reason why you see this seems to be because in floating window require('nvim-web-devicons').get_icon() is used with extension and not as the file name. While 'oil.nvim' seems to use file name. Those are mocked with "extension" and "file" categories respectively which act slightly differently. The best suggestion here is to wait for the first class 'mini.icons' support.