Thanks so much for making this PR, @V1rgul! I know you made it a couple of weeks ago as a result of our discussion in #382.

While this change fixes the code-point problem for the awesome-fontconfig, it actually further breaks other forms of awesome fontconfigs (baked-in fonts) that have different code-points that the patch.

What I'm planning to do at this point is merge this PR in and create a new font-group option for the baked-in option. This PR will get pushed up to next as part of a larger changeset, soon.

Thanks so much for putting in the effort to make this PR, and then keeping up with it over the last couple weeks. I really appreciate it =)

Haven't dropped this, by the way. Will be going in, in a slightly different form, soon...

@V1rgul - I just pushed some changes to next regarding nerdfonts, and am trying to sort out how to best work in the changes in this PR. An OS question:

This relies on the formal installation of Awesome Fontconfig in ~/.fonts, but I only see that as the recommended installation method on Linux. Does this work on OSX?
OSX Installation Instructions for Awesome Fontconfig: https://github.com/gabrielelana/awesome-terminal-fonts#how-to-install-osx

Is it possible to set the path to the mapping files as an overridable variable(s)? I agree that's the safest setting as detailed by the awesome fonts README, but I'm on Linux and I have opted to install an awesome-terminal fonts package which will have a different mapping file path.

@rhabbachi @bhilburn I fixed the conflicts and implemented a configurable fontawesome path ;)

@bhilburn does it need anything more before merging ?

Sorry for being AWOL on this, @V1rgul. I decided to wait until after v.0.6.0 to get this out, which I neglected to mention in this thread. Also, thanks for updating with a configurable path! That was actually one of my concerns.

The other primary thing I'm concerned about is this breaking other font types using the awesome-fontconfig but which aren't actually "Font Awesome". As an example, I use "Source Code Pro", which actually has most of the same code points as "Powerline Font Awesome", and thus works will awesome-fontconfig right now - this PR would break that, though, as I don't have the font map.

If this is the "one true way" to do code points with "Font Awesome"-based fonts, then perhaps it's time to break out "Source Code Pro" and other built-in fonts into their own font option. I certainly want to make the use of the 'awesome-*' fonts as easy as possible.

What are your thoughts on this?

@bhilburn I am on @V1rgul 's side.
The problem is that we use the internal API of awesome-terminal-fonts (= the codepoints), but we should use the public API (= the variables). Because of the absoluteness of the codepoints it might be broken in some circumstances. If a user still uses an old version of awesome-terminal-fonts he would see wrong glyphs now (since we switched the codepoints). And that might happen in the future as well.
And btw. you are using "SouceCode Pro" as a font, but that is just for text and powerline icons, right? The other icons that are displayed in the prompt are taken from "FontAwesome". That is done by fontconfig. Here is a list of glyphs in SourceCodePro.

If this is the "one true way" to do code points with "Font Awesome"-based fonts, then perhaps it's time to break out "Source Code Pro" and other built-in fonts into their own font option. I certainly want to make the use of the 'awesome-*' fonts as easy as possible.

I agree, maybe we need a new option for "SourceCode Pro". But for awesome-terminal-fonts we should stick to the default way, and that is through the font maps.

Thanks for the feedback, everyone!

Font-maps will be how we proceed, based on input from @V1rgul and @dritter. I will work on integrating this ASAP.

Just a note that I haven't forgotten about this. Just haven't finished integrating & testing =)

Any news for this? Been using it for a while now and works great for me.

@rhabbachi - We are working on getting it merged in #472 =)

@V1rgul - I'm actually going to close this PR since all of your commits are in #472, anyway.