Include a flag to replace the "circle" with a glyph from Nerd Fonts

[hasecilu]

Summary 💡

Currently in the languages section a circle using the "chip" color is printed along the programming language name, it would be more attractive to the eye to have the colored logo of the programming language instead of the circle.

Motivation 🔦

In the Nerd Fonts project there are a lot of glyphs directly related to a lot of programming languages (see non extensive list below, to be updated later).

• Ada: 
• Arduino: 
• Assembly: 
• Bash: 󱆃 / 
• C: 
• Clojure: 
• CoffeeScript: 
• Coldfusion: 
• C++: 
• Crystal: 
• Csharp: 󰌛
• Css: 
• Dart:  *ascii differs from logo
• Docker: 
• E-lisp: 
• Elixir: 
• Elm: 
• Emojicode: 󰞅 *no logo?
• Erlang: 
• Fish: 
• Fortran Legacy/modern: 󱈚
• Fsharp: 
• GdScript (godot): 
• Go: 
• Graphql: 󰡷
• Groovy: 
• Haskell: 
• Haxe: 
• HolyC: 
• HTML: 
• Java: 
• JavaScript: 
• Json: 
• Julia: 
• Kotlin: 
• Lisp: 
• Lua: 
• Makefile: 
• Markdown: 
• Nim: 
• Nix: 
• ObjectiveC:  *Use C again?
• Ocaml: 
• Org: 
• Perl: 
• Perl6 (now raku): *need rename?
• php:  /  / 
• Powershell: 󰨊
• Prolog: 
• Purescript: 
• Python: 
• Qml: 
• R: 
• Ruby: 
• Rust: 
• Sass: 
• Scala: 
• Scheme: 
• sh: 󱆃
• Sql: 
• Svelte: 
• Svg: 󰜡
• SystemVerilog:  *HDL
• SWift: 
• Tcl: 󰛓
• Tex: 
• TOML: 
• Typescript: 
• Twig: 
• Verilog:  *HDL
• VHDL:  *HDL
• VimScript: 
• Vue: 
• Xaml: 󰙳
• XML: 󰗀
• YAML: 
• Zig: 
• zsh: 󱆃

If a new entry in the config file is added, users could include the glyph if it exists and onefetch could replace the circle with that.

            let circle = "\u{25CF}".color(*circle_color);

    glyph: "\uf34b" # 

Example:

onefetch --icons

[spenserblack]

So you're proposing using the main language's logo as the "chip" for each language? TBH If we supported something like this I'd want to go a step further and show each language's nerdfont icon.

[hasecilu]

Yes, I mean to assign their corresponding icons to each language, in the picture I just used the Rust icon because it was an easy change, I'm not really good at rust so I don't know how to implement the proposed change.

[spenserblack]

I'm not really good at rust so I don't know how to implement the proposed change.

No problem. Let's give this issue some time for discussion before you make any contributions . In case we close this as "not planned" I wouldn't want you to do work unnecessarily. But even just updating languages.yaml would be a huge help 🙂

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Localghost385]

Is this as simple as adding a value in languages.yaml with the character and using that, or is there something I'm missing.

This is an example of a possible solution.

Rust:
  type: programming
  ascii: |
    {0}                 R RR RR
    {0}              R RRRRRRRR R          R
    {0} R RR       R RRRRRRRRRRRRR R      RR
    {0}rR RRR    R RRRRRRRRRRRRRRRRR R   RRR R
    {0}RRR RR   RRRRRRRRRRRRRRRRRRRRRRR  RRRRR
    {0} RRRRR  RRRRRRRRRRRRRRRRRRRRRRRR  RRRR
    {0}  RRR RRRRRRRRRRRRRRRRRRRRRRRRRRRR RR
    {0}    R  RRRRRRRRRR{1}=  {0}RR{1} = {0}RRRRRRRRRRR
    {0}     RRRRRRRRRRRR{1}=  {0}RR{1} = {0}RRRRRRRRRR
    {0}      RRRRRRRRRRR   RR   RRRRRRRRRR
    {0}     RR==RRRRRRRRRRRRRRRRRRRRRR===RR
    {0}     RR =  ==RRRRRRR  RRRRRR==  = RR
    {0}      RR =     ===========     = RR
    {0}       RR                        R
    {0}        R                       R
    {0}         R
  colors:
    ansi:
      - red
      - white
    hex:
      - "#E43717"
      - "#FFFFFF"
    chip: "#DEA584"
  chip_character: 

the only issues that i can see arising from this are whether or not to enable this by default, and whether there should be a chip_character value for every language in the yaml file, even if they don't have a nerd font glyph.

[Localghost385]

I've done a basic implementation without a flag,

I've got most of the basic functionality worked out, but there's still a few issues that need to be worked out,

• nerd font has surprisingly good coverage for the languages supported by onefetch, but there is still about 45 languages that don't have a perfect match. For a decent number of these, like Holy C and JSX there is very similar glyph, and another chunk are just a circle or square with text that would not be legible at that scale anyway. There are a few that just don't have any real logo, and a few more that cant really be represented properly by any other glyph that i know of, like idris and raku. I searched for the characters with this tool on the nerd fonts website, it's not a particularly forgiving search, so i might be missing some chars, but i spent a decent time fighting with it.

• I'm not sure if chip is a descriptive name for it, but possibly -C for the short flag, I'm not sure what the long flag would be.

If there's no glaring issues I'm missing, I'll make a pull request.

[o2sh]

The logos are so tiny 😄

[Localghost385]

lol.

my colorscheme doesn't contrast very well with the chip colour for these langs, but even then all of the characters are one space wide.

I don't know of any way to get around that though.

[spenserblack]

The logos are so tiny

#1308 (comment) Just happened to show two of the more detailed, and therefore hard to see, logos. It's not so bad with the C logo.

@Localghost385 you might be able to get a head-start by referencing the contributions here: spenserblack/gengo#345 and spenserblack/gengo#348. But I believe some invalid codes were included 😢

[Localghost385]

Here's another example.

I'll definitely check spenserblack/gengo#345 and spenserblack/gengo#348

In regards to legibility, there may be an argument for not using the logo for some languages like makefile?

[spenserblack]

there may be an argument for not using the logo for some languages like makefile?

You might be able to find a alternate glyphs for some. For Makefile, for example, try  or  instead of 

[spenserblack]

@Localghost385 FYI, if you're going to use the escapes: spenserblack/gengo#435

For example, for Rust (󱘗), use \U000f1617 (0 pad for 8 characters), not \uf1617 or \udb85\ude17. The former is an invalid escape (5 characters for a 16-bit code point), and apparently YAML parsers can't handle the latter (tried with yq, Ruby's yaml library, and Rust's serde_yaml).

Though I guess that depends on if you're planning on putting the literal nerd font character or its escaped Unicode in the data file (personally I prefer using escapes).

[Localghost385]

@spenserblack
I've been doing it like this, which seems like the rust way of handling unicode (According to this),
icon: \u{f031f} # 󰌟

But i could handle them in a more standard format,
icon: "\U000f031f" # 󰌟
The only problem with that is that it would no longer be able to handle them as chars
error: character literal may only contain one codepoint

It's not a big change, but at the same time I don't know if it's an issue to keep it this way.

[spenserblack]

Oh, are you hard-coding these in the Rust code? You probably want to put it in languages.yaml.

[Localghost385]

this is in the in languages.yaml

Rust:
  type: programming
  ascii: |
    {0}                 R RR RR
    {0}              R RRRRRRRR R          R
    {0} R RR       R RRRRRRRRRRRRR R      RR
    {0}rR RRR    R RRRRRRRRRRRRRRRRR R   RRR R
    {0}RRR RR   RRRRRRRRRRRRRRRRRRRRRRR  RRRRR
    {0} RRRRR  RRRRRRRRRRRRRRRRRRRRRRRR  RRRR
    {0}  RRR RRRRRRRRRRRRRRRRRRRRRRRRRRRR RR
    {0}    R  RRRRRRRRRR{1}=  {0}RR{1} = {0}RRRRRRRRRRR
    {0}     RRRRRRRRRRRR{1}=  {0}RR{1} = {0}RRRRRRRRRR
    {0}      RRRRRRRRRRR   RR   RRRRRRRRRR
    {0}     RR==RRRRRRRRRRRRRRRRRRRRRR===RR
    {0}     RR =  ==RRRRRRR  RRRRRR==  = RR
    {0}      RR =     ===========     = RR
    {0}       RR                        R
    {0}        R                       R
    {0}         R
  colors:
    ansi:
      - red
      - white
    hex:
      - "#E43717"
      - "#FFFFFF"
    chip: "#DEA584"
  icon: \u{E7A8} #  

the error occurs in the rust code generated from the yaml in languages.tera.

    pub fn get_language_icon(&self) -> char {
        match self {
            {% for language, attrs in languages -%}
                Language::{{ language }} => '{{ attrs.icon }}',
            {% endfor %}
        }
    }
}

[spenserblack]

Oh, OK, now I understand what you're doing. It's a literal string (not an escape) in the YAML, and then gets output just as it is in the template. So it's kind of like you're writing Rust strings, not YAML strings. Sorry, I missed that the snippets you were posting were YAML and not Rust.

This brings up an interesting thought: what should we ask/expect contributors to know? The Rust syntax for writing Unicode, or the YAML syntax?

[Localghost385]

The standard way seems best to me really.

If there's already a precedent of handling them that way (in gengo), and it's what most people will be used to it's probably the best solution.

[spenserblack]

In gengo's scenario it was ideal to do it that way, for 2 reasons:

1. If a contributor doesn't have a Nerd Font installed they should still be able to review the code (so no special characters like 󰌟)
2. gengo reads the YAML and writes Rust tokens, so the YAML should evaluate to the actual string value

Onefetch, like tokei, doesn't write tokens, but uses a templating language. So there's a bit more freedom in that you can write Rust syntax directly in the data. So it really comes down to a matter of preference I think. There's a bit of overlap between tokei and onefetch contributions. Tokei has set the precedent of writing Rust syntax in the data file (even going so far as requiring double escapes, 1 for JSON and 1 for Rust).

At this point I'm leaning slightly towards YAML escapes instead of Rust escapes, but I don't really have a strong opinion one way or the other. Just raising the question for consideration. @o2sh thoughts?

[o2sh]

Ideally, we would use the Nerd Font code point verbatim inside languages.yaml to facilitate future contributions and code reviews.

This means using \uf031f instead of \u{f031f}, and making the necessary conversion inside the tera template.

[spenserblack]

If we're fine with having the actual character in the generated code instead of the escape, I don't think we actually need to perform a conversion.

# input
nerd-font-icon: "\U0000e7a8"

// output
fn get_nerd_font_icon(&self) -> Option<char> {
    match self {
        // ...
        Rust => '',
        // ...
    }
}

[Localghost385]

I created a pr to get some feedback on the icons, most of the functionality is there but there's still some issues to be worked out.

#1395