Beta-testing 'mini.icons' #1007
Comments
|
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. |
|
First of all, thank you for this great new module! Just wanted to let you know it currently doesn't work with fzf-lua. |
|
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 |
This comment was marked as resolved.
This comment was marked as resolved.
@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 This means that telescope uses 'nvim-web-devicons' as You can check that 'mini.icons' does work correctly via 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.
@folke, thanks for early beta-testing! I thought that mocking all |
|
About that The offending line in 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 |
Yes, I figured this also some time ago. I planned to make fix this upstream by also recognizing
That was exactly what I thought about during writing that comment. Don't know why I didn't think about this sooner 🤦 |
|
require('mini.icons').setup({
extension = {
['ghci'] = {
glyph = '',
hl = 'MiniIconsPurple'
},
}
})
Results in: EDIT: |
|
Thank for this! Testing it right now.
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
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 🥳 |
|
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: |
|
Consider adding a
|
|
I've pushed some changes after early beta-testing. There is now better fallback to There is now fuller and (hopefully) smarter mocking in @wroyca, thanks for detailed feedback. Highly appreciated! Here are some thoughts:
@xarvex, the reason why you see this seems to be because in floating window |
## What is this PR for? Replace the icon support with the new mini library ## Blockers - [ ] echasnovski/mini.nvim#1007 (comment)
|
Sweet! Just merged my PR to use |
Very noice! Expecting bazillion issues about it now :) Is there a reason you still use |
|
That's just to lazyload |
|
For your use-case you should probably not use preload, since you're executing the code anyway, so there's no benefit and you can just define the |
|
Hm, OK. I would have assumed that this would conflict with how mocking is now done. But if it works, then fine. I don't think there is more 'mini.icons' can do here to make it easier for this type of mocking on user side, right?
Oh, well. It's already there, so let it be until it causes some issue. |
|
So for Either way, that |
|
Confirming the issue with TS is gone. Thanks! But now I've found another icon missing, again with Telescope:
The same happens with After looking at the code, I see you are prioritazing |
This is because Telescope calls |
|
Hello, is this normal ? mini.icons not working for me. Thanks |
Hi! No, this is not normal. It looks like you haven't updated 'mini.nvim' to latest |
|
It's awesome to see this plugin and the "mock" nvim-web-devicons. Another plugin that is quite popular in the community is |
Thanks, it's working ! |
|
Hello, some recent changes broke lualine. When I pin mini.icons to For reference, here is my commit with the changes I made and the (working) pinned mini.icon edit: This is the not working commit: 3c51394b8815e0cb9beb385909803cd4816951c4 version |
|
Is there a way to add an icon and a HEX code in the highlight? |
About mocking cmp.setup({
formatting = {
format = function(entry, vim_item)
-- replace kind with mini lsp icon
local icon, _ = require("mini.icons").get("lsp", vim_item.kind)
if icon ~= nil then
vim_item.kind = icon
end
return vim_item
end,
},
})
|
I am pretty sure it is not the problem with 'mini.icons' per se. What plugin is responsible for showing those icons and which icon-highlight pair do you expect to see there? |
thanks, it's lualine's problem |
Hello echasnovski, thank you for responding, I am very grateful for your plugin. I tried validating what you told me, the terminal in kitty, alacrity, blackbox, and iTerm, and vscode looks consistent with the glyphs. I tried changing the font that I created and using three of the most common ones, and it looks the same. So I thought it's not a problem with the glyphs because they overflow into the next cells. So it's not a configuration issue. If I disable the ability to extend the glyphs, the rest of the configurations will look bad. So if I just want to leave a space or add a hyphen, etc., I have to go through all the icons, adding a space. Could you please indicate how I can do this as you mentioned with: "MiniIcons.get()". At the moment, I tried applying by overwriting and customizing the ones I use most frequently, but it is a one-by-one task. thanks for you help |
I do not really understand the actual problem here. Icons (either in Most plugins which use icons already add a single space to the right of the icon. This is usually to allow those icons to be shown wider than a single cell, if both terminal emulator and font support this. I believe this is the case in the earlier screenshots. In theory, you can monkey-patch |
|
I don't know the exact settings, but most terminals can be configured on how to show those icons. |
|
Hi @echasnovski, I'm currently working on adding mini.icons first-class support for fzf-lua (almost complete btw), code can be found in the mini_icons branch, most of the logic is in the devicons.lua file. Some background, in order to achieve lag free-experience, fzf-lua runs heavy duty processing in an external process, AKA fzf-lua's Fzf-lua therefore does not call the This works great with The above presents an issue for fzf-lua, while I can easily replicate this logic, due to the The above isn't easy to work around from the external process with So, for now, I just added a simple check if the extension is the same as the filetype which is obviously imprefect and fails at the simple case of
-- mini.icons supports lookup by filetype
if not icon and STATE.icons.by_filetype then
if not vim.in_fast_event() then
local ft = vim.filetype.match({ filename = filename })
if ft and #ft > 0 then
local by_ft = STATE.icons.by_filetype[ft]
if by_ft then
icon, color = by_ft.icon, by_ft.color
-- Store in the corresponding lookup table so we don't
-- have to call `vim.filetype.match` a second time
if ext then
STATE.icons.by_ext[ext] = by_ft
else
STATE.icons.by_filename[filename] = by_ft
end
end
end
elseif ext then
-- HACK: since we cannot use `vim.filetype.match` we attempt resolving
-- using extension as filetype, while not accurate it works in many cases
local by_ft = STATE.icons.by_filetype[ext]
if by_ft then
icon, color = by_ft.icon, by_ft.color
end
end
endIf this isn't the right place for this disucssion let me know and I'll create a separate issue or we can also continue on the existing fzf-lua issue: ibhagwan/fzf-lua#1319. |
|
Hi, @ibhagwan! This all indeed looks fairly complicated :(
Apart from small nitpick details (like buffer contents is essentially not used and how cache works, which is subject to change), this is indeed what is done. I am afraid that heavy usage of As it might be a lengthy conversation, let's indeed continue this in ibhagwan/fzf-lua#1319. In an ideal world, I would have loved to not track special icons for extensions and filenames at all while completely relying on
The current approach of "try extension before |
|
After a lot of consideration and profiling on real world cases, I've just pushed several important updates. Most of them are about how "file" category is resolved. Here is a TL;DR:
See this comment for demonstration of main benefit of these changes. To counter increased memory usage, caching now has less duplication and seems to be as optimal as is reasonable. @mehalter, your idea about using less memory in caching was a good catalyst for this improvement. Profiling "before" and "after" on several real world use cases seems to indicate that in "clean" state there is mostly a slight improvement in both speed and memory usage. But assuming another Lua object containing used full paths (like is done in 'mini.files'), there is a consistent and significant (like 3-4 times) improvement in memory. The only thing worse is a first-call speed for paths without recognizable extensions (especially for 'file.with.many.dots.as.each.will.call.vim.filetype.match' cases). All in all, I hope that this concludes the overall redesign updates. There are possibly two more functions to consider for exporting ( |
|
I have a couple of minor nitpicks :-) (1) I feel the special icon for I personally patch my fonts non-monospaced as I feel it looks nicer, the icons are bigger and more distinct, however that causes the specialized README icon to look too big and portrude into the next char:
(2) Another issue I have is also realted to monospaced vs non-monospaced, some of the icons (e.g.
|
|
I have a question: how do i override builtin icon for file = {
["init.lua"] = { glyph = "", hl = "MiniIconsAzure" },
},was enough, now |
All hope was lost hours after this was posted when #1086 issue surfaced after the latest redesign. Turns out, the "extension" category did not have proper resolution of its own: "my.lua" extension worked (because Also with "extension" having its own resolution
@AlexKurisu, my bad, didn't have test cases for overriding of built-in file names (only for customizing existing ones). This now should also be resolved on latest
@ibhagwan, thanks for the nitpicky feedback! Answering it is the least I can do for your troubles of adding first class 'mini.icons' support :)
I am afraid, this is intentional. See this comment.
We can talk about this on a case by case basis. If I understand the issue, at least the following glyphs are troublesome (which are tall and narrow):
If there are some other ones, I am happy to discuss. Thankfully, all these icons should be easily configurable, so I hope they are not a huge issue. |
|
How do I differentiate between two completely different filetypes that use the same extension, for example Verilog and V (which are both .v)? |
The best answer is "the support here is limited". Which I think is fairly reasonable, because icons are returned only based on the string (extension name or file path). There is no other data available. The only thing that can be used here is an elaborate filetype matching based on pattern. Here is an example demonstrating the concept using built-in 'queries/.*%.scm' pattern to match 'query' filetype instead of 'scheme' which matches 'scm' extension. The #1017 discussion has another example with 'yaml.ansible'. Note: the |
None of this is a big deal, I’ll just create overrides, ty @echasnovski. |
|
After the latest addition of There will still be a plenty of beta-testing time in case anyone has a new feedback, which I am happy to discuss. |
Hi and thank you for this module again. I just had a small doubt with the tweak_lsp_kind() method. |
You don't have to use it to have icons in 'nvim-cmp'. As far as I understand, implementing proper require('nvim-cmp').setup({
-- ...
formatting = {
format = function(_, vim_item)
local icon, hl = MiniIcons.get("lsp", vim_item.kind)
vim_item.kind = icon .. " " .. vim_item.kind
vim_item.kind_hl_group = hl
return vim_item
end,
},
}) |
Works like a charm. Thank you soo much. |
|
An enhanced version of nvim-cmp code, as we have other plugins that utilize cmp (especially AI plugins). I prefer icons only, so I commented out the names of the sources. -- somewhere outside the setup function:
local kind_icons = {
ellipsis_char = "...",
Copilot = "",
Supermaven = "",
Codeium = "",
otter = "🦦",
Cody = "",
cmp_r = "R",
}
-- in the setup function
formatting = {
format = function(_, vim_item)
local icon, hl, is_default =
require("mini.icons").get("lsp", vim_item.kind)
-- If the icon is not found in mini.icons (is_default is true), use the fallback
if is_default then
icon = kind_icons[vim_item.kind] or ""
hl = "CmpItemKind" .. vim_item.kind
end
vim_item.kind = icon -- .. " " .. vim_item.kind
vim_item.kind_hl_group = hl
return vim_item
end,
fields = { "kind", "abbr" }, -- "menu",
}, |
I must say that be careful to remove menu field from formatting, cause in some LSP like jdtls (not sure if other LSP has the same behavior), menu source are not provide source information but method signature or something useful message.
The 2th column is the menu field from jdtls. |
@bassamsdata, I would still suggest using the version of code example from my comment, but with adding custom icon data in require('mini.icons').setup({
lsp = {
ellipsis_char = { glyph = '…', hl = 'MiniIconsRed' },
copilot = { glyph = '', hl = 'MiniIconsOrange' },
supermaven = { glyph = '', hl = 'MiniIconsYellow' },
codeium = { glyph = '', hl = 'MiniIconsGreen' },
otter = { glyph = '🦦', hl = 'MiniIconsCyan' },
cody = { glyph = '', hl = 'MiniIconsAzure' },
cmp_r = { glyph = 'R', hl = 'MiniIconsBlue' },
},
}) |
Thank you. True, this approach has the advantage of adding highlights and using the icons elsewhere while reducing the amount of necessary code. |
|
Not exactly an update on 'mini.icons', but closely related. 'mini.files' now computes prefix (which by default uses 'mini.icons' if it is enabled) only for visible items in preview. This was done to reduce the delay when first time previewing directory with lots of entries (as First focusing on path still may result in a delay though :( At least until 'mini.nvim' drops support for Neovim 0.9.5 which doesn't have inline extmarks. |
Use MiniIcons, cf. echasnovski/mini.nvim#1007
|
Thanks everyone for the amazing feedback! With the release of 0.14.0, 'mini.icons' is now out of beta-testing! |
and others
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:
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:
d.tsextension.What I am open for and welcome:
nf-md-alpha-*icons. For example, like this. It needs a reasonable suggestion, though.Is configuration intuitive enough?
Are default values of settings convenient for you?
Is documentation and examples clear enough?
Thanks!
The text was updated successfully, but these errors were encountered: