Include Lucide Icons

[Finii]

There is an Issue for adding the Feather icons:

• Include Feather icons #665

The Lucide icons are a fork of Feather, with a very active contributor scene:
https://github.com/lucide-icons/lucide

There were already some discussions ongoing, let put them here in their own topic.

[Finii]

Following comments I moved here (manually):

[Finii]

Originally posted by @danielbayley in #1095 (comment)

@Finii Suggesting Lucide icons, instead of Feather icons, as mentioned in #665. Lucide is a much better fork of Feather…

---

Ah, thanks for the hint.

Unfortunately they seem to be web- and single-icon-use-centric, as they do not keep codepoints constant.

I just opened up two versions 1/2 year apart or so, and in the new version they stuffed in more icons in between existing ones:

It is of course bad to change the codepoints, as terminal users address the icons solely by codepoints, and they rightfully expect their beautiful shell prompt to stay the same (icon wise) on updates. They seem to have not understood that codepoint stability is important for the font files. (It does not matter for usage via name, as typical web users do).

Of course we could - manually and laboriously - introduce some mechanism to add the codepoint guarantee, but with >1000 icons that would really be a maintenance burden.

---

🤔

And WHY do they add one arrow with filled head (green) and the other directions with open head (blue)?

😒

---

To make sure you understand what I mean (and because you seem to be involved with Lucide)

Assume we have a user that wants a fruit in the prompt. People tend to like their OS-icons in the prompt (for reasons that are beyond me, but that does not matter).

This person installs a Nerd Font, finds that the fruit has codepoint U+F12B and uses that icon in the prompt via `echo "\uf12b".
Then Nerd Fonts updates the Lucide Icons and releases new fonts and they will of course be automatically installed on that user's machine.
Unfortunately the Lucide people decided to put new icons between the fruit and the start (instead of appending the new icons to the end) - and when the update is installed and that poor Apple user is presented with a angry icon in the prompt instead :-o

This is nothing Nerd Font can/want to follow. I assume Lucida takes all currently available svgs and sorts them (alphabetically?) and dumps them in a file. After adding icon aaa_my_icon all the icon codepoints shift by one :-( Nerd Fonts would need to fix that, resort the icons to keep the same symbols on the same codepoints and shift all new icons to the back.

In fact we do this already for some icon sources; but they do not change as drastically as Lucide.

Maybe you want to bring that problem up at Lucide. For me ... those icon sets grew me grey hairs...

---

Addendum:

#365 (comment) says (see 'update codepoint stable' column):

For the octicons we re-establish codepoint stability with some scripts:

https://github.com/ryanoasis/nerd-fonts/tree/master/src/glyphs/octicons

analyze creates a mapping file with the initial codepoint-symbol association. Then on symbol font updates generate transmogrifies the symbol font to a new one with corrected codepoints, which can fail in various ways.

[Finii]

Originally posted by @danielbayley in #1095 (comment)

in the new version they stuffed in more icons in between existing ones
you seem to be involved with Lucide

@Finii Yes I added many of those icons myself 😅 But had no control over the associated codepoints…

Which I agree should be kept stable. I already understand the issue since running into it myself, with my vscode-lucide-icons extension (almost ready!) as VSCode also operates on font codepoints for icons… I dealt with it there by writing a script based on matching up names, using the opentype package, to find the correct unicodes after a font update (sounds similar to how you mention addressing the problem with octicons) But this is not really the proper longterm solution…

I just opened up two versions 1/2 year apart or so
they do not keep codepoints constant.

Comparing the latest font with an old version will have different codepoints (as many new icons), but just recently I think the underlying issue should have been fixed in lucide-icons#1413, so this should hopefully not be a problem going forward… @Finii See relevant issue/PRs: lucide-icons#514, lucide-icons#1413 and lucide-icons#1599.

WHY do they add one arrow with filled head (green) and the other directions with open head (blue)?

Not sure exactly what happened there, obviously they weren’t designed that way… It might have something to do with the source SVGs not being outlined properly before the font gets generated (all Lucide icons are purely stroke based). I think this should also be fixed by the updated build process, implemented in lucide-icons#1413, as mentioned.

cc: @ ericfennis @ schmidt-oliver @ karsa-mistmere

[Finii]

Originally posted by @schmidt-oliver in #1095 (comment)

Comparing the latest font with an old version will have different codepoints (as many new icons), but just recently I think the underlying issue should have been fixed in lucide-icons#1413, so this should hopefully not be a problem going forward… @Finii See relevant issue/PRs: lucide-icons#514, lucide-icons#1413 and lucide-icons#1599.

The underlying problem should be fixed after pull request #1599 is merged. However, I can't promise that it won't cause problems when icons are renamed or deleted.

[Finii]

The underlying problem should be fixed after pull request #1599 is merged. However, I can't promise that it won't cause problems when icons are renamed or deleted.

After looking into the PR I think this is how they did it:

• Sort icons by added date
• Sort icons with same added date alphabetically
• Create list of name-to-codepoint that ends up in packageData.json

Which of course breaks all codepoints if a rather old icon is ever dropped. There is not even a real way to fill the then-vacant codepint with a new icon to avoid shifting, except by lying about the added date.

Unfortunately there has been a nice and clean solution (with a dedicated table), but that has been removed from the relevant PR:

With this comment: lucide-icons/lucide#1413 (comment)

That is really a pity and I do not understand the problem with fetching the file (i.e. info.json) and commiting back changes if icons have been added.

[danielbayley]

The underlying problem should be fixed after pull request #1599 is merged. However, I can't promise that it won't cause problems when icons are renamed or deleted.

After looking into the PR I think this is how they did it:

• Sort icons by added date
• Sort icons with same added date alphabetically
• Create list of name-to-codepoint that ends up in packageData.json

Which of course breaks all codepoints if a rather old icon is ever dropped. There is not even a real way to fill the then-vacant codepint with a new icon to avoid shifting, except by lying about the added date.

Unfortunately there has been a nice and clean solution (with a dedicated table), but that has been removed from the relevant PR:

With this comment: lucide-icons/lucide#1413 (comment)

That is really a pity and I do not understand the problem with fetching the file (i.e. info.json) and commiting back changes if icons have been added.

Yeah I think this algorithm needs to be rethought, with a focus on stable codepoints, taking into account the possibility of old icons being removed/renamed… and also aliases @ericfennis @schmidt-oliver

@Finii Might be worth opening a new issue there, for better visibility…

[Finii]

Closing because transferred to #1095

[Finii]

See also

• Lucide icons solid #1606