Produce a specification and/or informal standard

[sedwards2009]

It is interesting to see just how well this technical approach works in the wild, but right now it is a bit of a hack which throws in 3000 odd icons and stirs them up. This project would be more useful and interesting if it was based around of more formal specification which not only documented which icons go where in the unicode private use area, but also made a careful selection of icons which are really useful in the context of the terminal.

This would provide a more stable base for applications and terminals to build on. A specification should be quite conservative. Once something goes in you can't take it out.

Random thoughts on how to do this:

• Icons for file types are the most useful types of icons. This is an obvious place to start. Stay with actual file types and established languages, and avoid file types which are bound to one specific application (i.e. grunt, gulp etc)
• Icons for common things and ideas in terminal apps also make sense. 'Home', 'email', 'branch' and 'merge' in git etc.
• Avoid icons which are already covered else where in unicode. (i.e. emoji has heaps of overlap with current selection of icons.)
• Avoid icons which are trademarks and companies. They're just too volatile. (Do we want a MySpace icon? What about SoundCloud? Will they be around at the end of this year?)
• Specify how many character 'cells' the icons should take up. In a terminal most chars should take one cell, but Chinesse and other asian scripts take up two(!). Emojis also need more space. iTerm2 on macOS renders them over two cells, but advance the cursor one cell. (I do the same in my terminal emulator.)

[sebastiencs]

Hi @sedwards2009 and thanks for taking the time to write this.
I agree that icons should be selected carefully, I already regret linea because this font wasn't intent to be in terminals and it's not really nice. I'll probably remove it.
Also there is the script build.sh that allows the user to add any font to be included easily.

I'm not sure to understand what kind of documention you are suggesting. Something to describe each icons and how to use them ?
Like:
the icon x can be use with files extensions .ext the icon y can be use with email message

[sedwards2009]

The difference between a standard and an implementation like what you've done right now, is that a standard describes what an implementation has to do, and we would all be free to have multiple implementations with different icon styles etc etc. I work on a terminal emulator and it has to support a number of standards and de facto standards. I would love to be able to directly support special terminal icons up in the unicode special use area, but we would first need agree on (i.e. specify) what exactly these icons are and their code points. No one wants to add support to their software for one specific project like this one, it is too narrow, but a standard is much broader.

Nailing down what the icons are and their unicode code point would make it much clearer for users and implementers of these icons-in-terminal to know what the effective "API" is. This would provide a clear and stable base which people could use in their terminal based tools and also for terminal emulators. I think people would be more confident following a standard than just what-ever some project on github happens to do today.

Currently there are just too many icons, and too many with overlapping and redundant meanings. It is not stable or well thought out enough, (case in point linea), it may change over time.

Regarding the form of the documentation I'm requesting, it would mostly be a list of code points, and a description of the icon. For example:

Code point	Name	description
0xF001	PYTHON_FILE_TYPE	Python source file
0xF002	RUBY_FILE_TYPE	Ruby source file
0xF003	PLAIN_TEXT_FILE_TYPE	plain text file
...	...	...
0xF1001	SCM_MERGE	Merge operation in a VCS
0xF1002	SCM_BRANCH	Version branch in a VCS

An email message icon may not be needed as it is most likely already covered in the emoji part of unicode. But having said that, an email message icon which takes up one and only one character cell may be worth including. (Most emoji fonts have wide glyphs which take up at least 2 character cells if you try to fit them into a terminal emulator.)