Scoring of initialisms is much worse than sublime, emacs about fuzzy-finder HOT 27 OPEN

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.

from fuzzy-finder.

+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.)

from fuzzy-finder.

+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

from fuzzy-finder.

+1

from fuzzy-finder.

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

from fuzzy-finder.

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:

from fuzzy-finder.

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.

from fuzzy-finder.

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?

from fuzzy-finder.

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 .

from fuzzy-finder.

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

from fuzzy-finder.

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 :(

from fuzzy-finder.

@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"

from fuzzy-finder.

@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.

from fuzzy-finder.

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.

from fuzzy-finder.

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

from fuzzy-finder.

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

from fuzzy-finder.

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.

from fuzzy-finder.

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.

from fuzzy-finder.

confirming, beta version is much better

from fuzzy-finder.

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.

from fuzzy-finder.

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.

from fuzzy-finder.

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

from fuzzy-finder.

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

from fuzzy-finder.

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

from fuzzy-finder.

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.

from fuzzy-finder.

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.

from fuzzy-finder.

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)

from fuzzy-finder.