User-configurable icon-configs: Worth it?

“What?”

I’ve opened this for discussion and feedback regarding a feature I’ve contemplated adding for a while now: the possibility for users to define their own icon-matching rules, which would greatly simplify the process of adding an icon to multiple paths. Moreover, it would give users an opportunity to replace filetypes they don’t like or use with ones more relevant to their interests.

v2.0 introduced the ability to assign icons by customFileTypes, but this isn’t an exhaustive solution for several reasons:

1. It forces users to define new language-by-extension mappings for the sake of showing an icon.
   Fiddly at best, excessive at worst. Not to mention not every user wants the language-per-filetype association in their editor.

2. The customFileTypes setting only accepts fixed strings for matching filetypes. E.g., php for matching *.php files, but not php[0-4] or even *.php. No globbing, no regex, and no directory-specific matching is possible. For any user looking to map icons by directory, it’s back to the old-school CSS solution.

3. The config setting itself is somewhat secluded. Even though it’s been supported by Atom for a while, there’s no corresponding panel in the Settings View, which means it isn’t immediately obvious to everybody.

Our icon-config

I developed the config format intending to make it open-ended and extendable, but later decided it wouldn’t be worth the “added complexity” (see 7b2f897 for my thoughts on that…).

Lately, however, I’ve been reconsidering. Users will still have their stylesheets, of course, and that will always take precedence over everything else, but being able to hook into the regex-powered monolith that’s driving this package would give power-users a much cleaner alternative to stylesheet stuffing:

	# Unoriginal example:
	"Obscure Templating Language":
		icon: "mystery"
		match: /mystery/.*?/templates\/.+\.html?$/i
		matchPath: true
		colour: "medium-blue"

The above rule would add the mystery-icon and medium-blue classes to any html or htm file located in a descendant directory of a folder named mystery. Certainly not a common scenario, but we all know how excessive and ugly the equivalent Less code would need to be to achieve a similar effect.

Admittedly, another reason justifying user-configurable icon-configs is that since v2.0, styling icons for filetypes is much more cumbersome (sorry guys, it’s a necessary evil). There’s more copy+pasta of font-sizes, colours, font-families, etc… and adding icons by its raw codepoint isn’t exactly fancy, either.

“So what’s the freaking problem? Add it already!”

It’s been my experience that all code boasts no more than two of three properties:

• Writability: Power packed in a few keystrokes - Perl, awk, sed, shell-scripts, APL, etc
• Readability: Clean, sensible and reader-friendly - Markdown, Python, etc
• Regularity: The code is sane. Logical, well-structured, and enforces a pattern - C, Assembly, Lisp, Fortran, etc

Right, well… our config has a perfect balance of both writability and readability. Hairy regex notwithstanding.

It suffers in the regularity department: e.g., how many people can really follow the config’s format? I often feel like I’m the only one who knows what the hell is going on in there. Truth be told, there’s a lot that’s happening, and it’s difficult to explain how it unfolds to generate the compiled icon lists loaded at startup.

So my current reservations lie with… well, not knowing how to present this to the majority of users, and how to stress that this is more geared for hacker-type users familiar with regex, and not a common replacement for one’s stylesheet…

Man, I hope this rambling crap’s made sense.

/cc @DanBrooker /cc @MiracleBlue - For reminding me about the unpleasantness of codepoint-copypasta /cc @50Wliu - Because you’re a hell of a lot better at making balanced, realistic decisions than I’ll ever be

[DanBrooker]

@Alhadis you really don’t need my say so, this project is more yours than mine at this point. Do whatever you think is the right move.

[Alhadis]

Alright, here’s the roadmap for 2018:

1․ Publish to npm

There’s simply too much good stuff locked up in config.cson, and it’s only reasonable to assume it’s going to keep growing in the amount of information it contains. Because of how closely file-icons tracks updates made to GitHub’s Linguist, we’ll always have a wealth of format-related data of potential use outside Atom.

2․ The data stays here Screw that. Time to make this portable!

UPDATE: Changed my mind, largely due to the unpredictable hostility of apm and recent shit-fighting with npm (which has major DWIM issues). See my comment further down the page.

I’m reluctant to move the config to its own repository, because file-icons is already split into 3 or 4 separate repositories as it is. Heck, it’s already confusing to contributors on where to send a PR to have a new icon added.
What I’m considering is publishing file-icons to NPM under the name file-icons itself. This sly hack will depend on the generosity of @basarat to transfer ownership of the currently-registered file-icons package (which… actually seems to be “officially” registered as fileicons instead, sans hyphen). Once transferred, we can leverage .npmignore and export-ignore attributes to filter Atom and NPM-specific files, respectively.

There shouldn’t be any compatibility issues here, but given APM and NPM’s flaky histories, I can’t be certain. @50Wliu, I’m paging you in case you know of a time when homogenous package registrations has caused complications in the past, or something. E.g., APM downloading the package tarball from NPM instead of atom.io, or something to that effect.

3․ Replace .icondb.js with a compact binary representation

Reading, parsing and evaluating a huge-ass array isn’t an efficient way of loading the package’s database. Doing a single-pass evaluation of a bytestream with full control over serialisation and hash tables presents an interesting opportunity to improve performance. The reduction in filesize and elimination of hideous but inevitable diff-noise make this a tempting solution.
Obviously, the format will need to be very well-documented if it has any hope of making sense to future maintainers, which I wholeheartedly hope to do. Along with everything else I’ve yet to finish doing for this package which I’m behind on.

@DanBrooker You have the final say on what I can and can’t do, so it’s up to you to give the green light.