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