Atom: V2 task list

[Alhadis]

V2 will be a non-trivial release building upon the icon service introduced in Atom 1.2. Because this introduces breaking changes to customisation, it's pitched for a major release... which presents an opportunity to introduce other features of considerable importance. This tasklist was opened to provide a central platform for feedback and discussion.

Tasklist and progress tracking is now managed using a GitHub project.

To begin testing v2, run the following:
Still being developed. Please hold off until it's stable again.
Stable again. Go nuts:

cd ~/.atom/dev/packages/
git clone https://github.com/DanBrooker/file-icons.git
cd file-icons && git checkout v2-staged
apm install .
atom -d .

Related pull-request: atom/tree-view#966

Key features

• Case-insensitive matching:
  Capitalisation no longer matters for (most) extensions: .HTML, .html or .hTMl all test the same.

• Easier customisation:
  CSS classes are now used to set colour and icons, sparing users from having to include Less files or squabble with package/theme-specific styling. Icons can be easily changed with a single rule in a user's stylesheet:

  // Not a fan of elephants? No problem.
  .php-icon:before { content: "\f147"; }
     
  // Something that suits your theme a little better...
  .medium-orange { color: #b8743d; }
  

• Language overrides:
  Icons will change in response to user-set languages for certain files.

• More maintainable:
  File-matching is now handled with a configuration file instead of burying hacky patterns in Less source. A priority property also allows easier sorting of which patterns are matched first.

• Modeline/hashbang recognition:
  Files with #!/bin/sh or the like will now display accurate icons

[Alhadis]

@ccorcos, you'll be happy to know shebang recognition is really starting to shape up:

[Alhadis]

Hashbang and modeline recognition is done and working a _hell_ of a lot better than I expected to:

• The feature is non-blocking because file scans are performed asynchronously
• It's fast because Atom only sips the first 90 bytes of each file before matching its content against modeline patterns
• Empty or obvious binary files (like images and zip folders) are skipped, so opening a folder full of JPEGs won't waste cycles
• Each file's size and modification times are cached for the rest of the workspace session, making sure rescans are only done when changes are detected.

There's a slight flicker of the original icon when a user opens a folder for the first time, but the results are stored to disk and reloaded between sessions. It should be noted rescans will still be done upon startup to see if the file's header has changed... it just means the user won't notice an ugly icon-flicker.

Finally, as if that wasn't enough, both hashbang and modeline options are individually configurable in the package settings. If a user disables both, no filesystem scanning is done whatsoever (just in case).

This is strictly reliant on atom/tree-view#859 to be fast and performant, because it's reusing the filesystem calls that the tree-view package has already made to list the files. No extra overhead is being spent querying the system.

Seriously, I'm really happy with this. Once it's been thoroughly-tested (and the cache-management code refactored), it should kick an immeasurable volume of ass.

[Alhadis]

Okay, this is the point where I need feedback on something. Is having icons for JS/CSS framework files a good idea? And should we have a package option to disable them if a user chooses?

Normally I avoid adding settings that do whatever a user can already do with CSS... but if a user wants all JS and CSS files to show their proper icons, they're faced with a lot of stylesheet hackery. Makes sense to me, but part of me feels it's overdoing it.

Paging other maintainers for opinions: @ckross01, @DanBrooker , @astephenb

[ccorcos]

That would be cool if you ask me :)

[DanBrooker]

I'm not sure how useful the framework icons are, they affect relatively few files and in my experience are located in a dependencies directory which isn't viewed most of the time.

Is there anyway to split them into another package?

Also keep up the great work 👍

[Alhadis]

Thanks!

Well, the icons are already included with the existing icon-fonts (Mfizz, Devicons, etc). I figure I may as well put them to use for something... (they are, after all, contributing to the package's size, heh).

Do you want me to remove them?

[DanBrooker]

No need to remove them, but maybe don't go out of your way to add new ones

[Alhadis]

I won't, don't worry. I freakin' detest frameworks, anyway. :')

Do you think I should bother with the aforementioned package setting, mate? I'm getting the impression it'd probably be overkill..

[DanBrooker]

nah don't bother with a setting

[Alhadis]

Aye-aye, mate! Makes my life a whole lot easier, haha.

I can't wait for you guys to test this in action (once Atom finally merges my PRs... I'm hoping it'll be before Juno hits Neptune)

[DanBrooker]

I look forward to it 🚀

[Alhadis]

Update: This is going to take more work because @as-cii doesn't want the interface being too complicated due to perceived inconsistencies with how different packages consume the service (inconsistencies, mind you, which are the fault of two different versions of a File and Directory class floating around). So now I just have to hope the added filesystem calls aren't going to slow everything down.

[Alhadis]

Huge bunch of PRs merged!

Ignore the above comment, it turned out to be a non-issue when I noticed there was virtually zero lag in using lstatSync. Gotta friggin' love V8 and libuv. =3

Hopefully the remaining two PRs get merged and everything ships soon in a stable Atom release. Can't wait for you guys to see this. =)

[Alhadis]

Alright, now we're ready to begin testing!! Atom 1.11.0 has just been released, and it includes most of the PRs that're needed to let V2 work.

Everybody should test the hell out of this... I've updated the original post with instructions on how to setup a development version of the package.

[Alhadis]

Sigh... and changes in Atom's editor API has broken the feature for changing icons when overriding grammars.

Not sure whether to burn this mess of code and start afresh, or just drop the feature... either way, this will need to be rewritten again, because (barring the config), the code itself will be unmaintainable. It's too event-driven as opposed to _file_-driven, which has resulted in Java syndrome.

..... ugh....

[DanBrooker]

Oh that sucks, I've been hoping this would be live soon with all those merged PRs

[Alhadis]

It's fine, it works. It's just that icons don't update when changing a file's grammar... there're no other issues otherwise..

[Alhadis]

BBL, rewriting this properly as a way to distract myself from crippling depression.

[Alhadis]

@DanBrooker Alright, bad news and good news.

Bad news is there's one more PR that needs merging.

Good news is that this will actually be maintainable. :-) You know you've done a shit job when you go to fix a regression, and you can't even figure out your own fucking code. The spaghetti logic was probably a by-product of my unfamiliarity with Atom's APIs at the time I started... as I've worked on this, I built up a mental backlog of all the things I should've done instead.

Guess the first attempt can be considered a warm up.

[DanBrooker]

@Alhadis yeah that sounds about right, I always find it's better the second time.

[Alhadis]

It's ironic how little Atom's icon API is now being used.

It's basically a glorified FOUC-suppressant at this point.

EDIT: Actually, it's even less than that. :| Not using the API doesn't even show icon-less files in the panes, for god's sake. That's how much heavy-lifting this code is doing...

It gets better, though: if I'd taken this approach to begin with, we wouldn't have to have waited on the Atom team to merge half those PRs to begin testing. We could've started using/testing this months ago.

Don't know if I should laugh or cry right now.

[Lakston]

I'll admit that having individual framework icons is very appealing to me so, since you asked for feedback, I'm all for it !

If you need any help for the 2.0 please let me know and I'll do whatever I can.

I only use probably 3 or 4 package on atom but I could not live without this one so I'd be happy to get involved.

[Alhadis]

Hey @Lakston, glad to hear it! We'll definitely need thorough testing once this is stable.

@DanBrooker Don't think there's much point in waiting for atom/tree-view#966 to be merged, honestly. With all the monkey-patching I've had to do to Atom's problematic packages (e.g., fuzzy-finder, find-and-replace, etc) I may as well tackle the tree-view's drag-and-drop in a similar fashion. I'd rather not wait until Atom v1.15 or however long it's gonna take for the PR to be merged upstream...

[DanBrooker]

@Alhadis yeah might be time to just ship it

[Alhadis]

Hacking tree-view isn't gonna work after all... we're just gonna have to roll with it until atom/tree-view#966 gets merged. Not that it's a massive issue, but there might be some weirdness with moving certain files between directories (as in, those whose icons are assigned from a hashbang/modeline).

[DanBrooker]

I think merge into master, prep for release
open issues for known bugs
have some people test it
release
🎉

[Alhadis]

Gonna track progress using one of these new-fangled project thingies that were introduced earlier this year. Less fiddly to update.

[Alhadis]

Nearly finished. Just wanna say this is bordering on being a full-blown filesystem API in its own right.

Really happy with how this has turned out. =)

[DanBrooker]

You've really outdone yourself :shipit:

[Alhadis]

Dinner's on the table. Bring a fork.