Scoring of initialisms is much worse than sublime, emacs

[diiq]

Fuzzy finder scores strange, middle-of-word matches higher than perfect initialisms. Here's an example:

I am working on a project with a file called ImportanceTableCtrl.js.

I would like to type 'itc' and get this file as the top listing.

Atom's fuzzy finder gives me this list:

The file I'm looking for is not on the list. There's essentially no chance in hell that any of these files are the files I intended to ask for when I typed 'itc'. They're middle-of-word matches and middle-of-name initialisms. In order to get to the file I want, I have to delete characters and start over.

For comparison:

Sublime succeeds perfectly. See how the spec (a one-letter-longer initialism) is the next result? And it highlighted the characters it's matching, so I can see why it chose the files it chose.

Emacs gets the intended file as the second result, and the spec as the first. Ideally, the shorter name should be first, because I can always keep typing to get to the other. No one's going to be charmed by the interface, but it did the job -- finding the file only took one more keystroke than in Sublime.

[GrantSP]

Even with relatively simple searches of contiguous letters Atom fails to highlight the correct match.

Take this example. (there more files in the actual folder, but only these files are relevant to the search)
You know all the files have the prefix 'ski_' so you would skip that and type the first letters of the file you want. In this case: 'set'.

ski_activeeffectswidget.psc
ski_configbase.psc
ski_questbase.psc
ski_settingsmanager.psc
ski_widgetbase.psc

Invoking 'fuzzy find' in Atom and typing 'se' highlights firstly ski_questbase.psc. Then adding the 't' to make 'set', highlights ski_configbase.psc. Even though 'set', as a contiguous search parameter, doesn't exist in that name. The desired file, ski_settingsmanager.psc, which does have that letter combo is on the bottom of the list.

Sublime Text correctly highlights it, and in fact does so with only 'se', as that combination exists earlier in the filename and hence more likely to be what you are after, than the alphabetically listed higher file, ski_configbase.psc which also has 'se' in its name.

[giladgray]

+1 this is a major usability error in the fuzzy finder.

I've found that adding even one character of the file extension causes the fuzzy finder to suddenly work as expected (itc.j in the original comment, for example) but that's still significantly worse than the experience in Sublime.

I use Atom with a very large repository (2000+ source files, 10k+ total files) and when I try to fuzzy find an initialism it suggests files that don't even come close to what I typed. A search for 'tbbm' (trying to select ToolbarButtonModel.coffee) suggests "test-plugins/workspace/distributed-tests/distributed-tests.iml" as the first result, which doesn't even contain a single 'b.' Amending my search to 'tbbm.c' pops the correct file to the top. (But 'tbm.c' puts that file at the very end of the list.)

[calebmeyer]

+1 Same issues. Working on rails, I type ac (and then o, and then n) for application_controller, but it always comes up with application.rb

[tuckbick]

+1

[jeancroy]

atom/fuzzaldrin#22 should cover this, I migth add your case to the test

[Soleone]

i agree, this is actually the major issue with atom right now compared to sublime. i hope this gets the prioritization that it deserves. i talked to a couple of people at work and they all agree that this is the most annoying issue and for some even showstopper to move away from e.g. sublime.

no exaggeration, 75% of the time the file i'm searching for is not at the top (like it used to in sublime) and sometimes it's even buried below the fold. this is in a huge rails project with 10,000 files.

the following example illustrates it perfectly:

i want to open a file called _notification.html.erb. look at all the characters i'm typing and it still does not even show up:

only once i add .e it finally moves to the top:

[jeancroy]

Ok. This is because

1. Your request is valid for both the *.liquid and the *.erb files
2. Fuzzaldrin have some preference for shorter entry, this should work in favor of your _notification.html.erb over something_notification.html.liquid
3. Unfortunaltely for this case, fuzzaldrin also prefer entry that are less deep. Your .erb file is 4 directory deep while .liquid are 3 directory deep.

I believe the new way I handle dept penalty as well as character position bonus in PR#22 should work in your favor. However in the mean time typing something like _not.erb should do the trick. IE it's not about typing more as much as typing the difference from what is seen so far.

[Soleone]

thanks for the quick reply and explanations, appreciate it!

you're right that using _noti.erb brings it up. in general i feel that the scoring should favor files that match the beginning of the filename no matter which directory. so if i type _notifi are there really a lot of use cases where it makes sense to not have all files that start with an exact match to be right at the top?

[jeancroy]

Scoring of the beginning in current version, only apply to first letter. eg both _ match.
I've changed it so every char has a preference for being toward the start (and the strength of that preference decrease as char are near the end of the string) So that should help your expectation.

Directory depth definitely play a role. An exact match at the start buried 30 directory away might be unexpected. It's just I feel the current directory dept penalty was too strong, again adjusted .

[Soleone]

❤️ thanks! once this goes out and i can test it out, i can provide more feedback

[jesseleite]

I'm having same issues. In this screencast example, I'm looking for Model.php deep within /vendor. You'll see it exists in sidebar, but fuzzy finder doesn't show Model.php within the result set unless I explicitly type 'Model.php' with file extension. (Note: I have 'Exclude VCS Ignored Paths' unchecked, so Atom is indexing within /vendor.)

Example Screencast

As a long time Sublime user, and a recent convert to Atom, this is one of my biggest gripes so far :(

[jeancroy]

@jesseleite : one thing improved in atom/fuzzaldrin#22 is grouping of character as well as exact match. So things that contain model as a word should rank before those that contain model as individual characters eg "smoke.default"

[jesseleite]

@jeancroy Yeah this scoring algorithm stuff is pretty over my head. I don't want to beat a dead horse, but I find it's very well handled in Sublime Text. Is Sublime's scoring algorithm publicly known? Honestly, it's pretty much the only thing I miss from Sublime.

[dsernst]

i agree, this is actually the major issue with atom right now compared to sublime. i hope this gets the prioritization that it deserves. i talked to a couple of people at work and they all agree that this is the most annoying issue and for some even showstopper to move away from e.g. sublime.

This is the prevailing view by everyone who's used Atom on our team, too. Even one of its loudest proponents switched back to Sublime because he found the fuzzy-finder just too frustrating to deal with.

[blairanderson]

The scoring mechanism for the github file finder is far and beyond better than this one currently used.

Can add attempt to add this with another config mechanism?

https://twitter.com/tmm1/status/659781507041529856

https://github.com/joshaven/string_score

[Soleone]

that might be interesting if an open source library can be used instead of having to maintain separate scoring algorithm

[jesseleite]

Hey @blairanderson @Soleone, the Atom Beta stream has an experimental setting that you can enable, which swaps out the fuzzy finder algorithm for @jeancroy's fuzzaldrin/plus. It's still experimental and might need some tuning, but it's MUCH closer feeling to Sublime's fuzzy finder. Just install Atom Beta and enable the following under fuzzy-finder settings.

[Soleone]

Hey @jesseleite, I can't speak for @blairanderson but from my side I am already using @jeancroy's version right now. It does work great!

@blairanderson maybe give that a try if you haven't already and update here if it behaves just as good, worse or better than the github version.

@jesseleite In any case I think the main takeaway here might be that if https://github.com/joshaven/string_score solves the issue as well it might be easier to switch official Atom search to that instead of @jeancroy's version because it's another modularized and optimized project with its own test suite.

[blairanderson]

confirming, beta version is much better

[jesseleite]

might be easier to switch official Atom search to that instead of @jeancroy's version

Shhh, you might make the @jeancroy cry! He's put in a ton of hours into that thing :)

Anyway, I can't vouch for one or the other since I don't know the nitty gritty details. However, @jeancroy did open source and modularize his. However Atom implements, it'll obviously stay open source.

[jeancroy]

In any case I think the main takeaway here might be that if https://github.com/joshaven/string_score solves the issue

Classic fuzzaldrin is already a wrapper arround of joshaven/string_score. Basicaly that's the starting point we are trying to improve.

[jeancroy]

@blairanderson command-t scoring is sound too. Would be interesting to compare results.

[jesseleite]

Is there difference between CMD-T and CMD-P?

[jeancroy]

command-t is the name of a project used by vim https://github.com/wincent/Command-T

[r-owen]

I'm glad a solution is nearing. I tried recently to switch from Sublime Text, but gave up (again) because one of my projects has a huge number of files and Atom's fuzzy search proved essentially useless, whereas Sublime's fuzzy search handles it just fine.

[jeancroy]

Please try the alternate scoring option.
And report any result worse than sublime here: https://github.com/jeancroy/fuzzaldrin-plus
I'd be happy to git it a try and make your use case fit.

[r-owen]

Thanks. I gave it a try and found it a huge improvement, but still not as good as Sublime Text. Details posted here: #21 (comment)