Finder should prioritize order based on most frequently used.

[hdavidzhu]

Similar to Google's search omnibar. I open some files way more than others, and would like those files to be at the top of my results list.

[lasekio]

:+1:

[lee-dohm]

When do you want it to prioritize order in this way? Before you start typing anything? Only on ties? Or do you want it to do some sort of weird partial sort where even a closer typed match could be beaten by a file used more often?

[hdavidzhu]

Behavior-wise, I would probably want caching for the files that I search when that project is open. During that session, files that open more would gain additional weighting, something like a history weighting.

In the beginning all files can have the same weight. Eventually, this weight will shift depending on the opened history. It could be duration opened, how many times opened, etc.

I would imagine the ranking algorithm currently has its own weighting. (I have no idea how this sorting works haha). This could be another weight. In terms of the balance, I guess that would take some finagling.

So tl;dr, probably the third option.

If Atom preserved project/repo cache files, there could even be a more persistent history.

@mpokress

[lee-dohm]

I think we would have to be really, really careful to not break people's expectations if we were going to weight things on something other than "best match".

/cc @jeancroy (who did a bunch of work on enhancing the fuzzy match algorithm recently in https://github.com/atom/fuzzaldrin/pull/22)

[jeancroy]

Yeah, that's a non obvious request because if two path are different, then we should be able to select one of them based on the query. So it's more of a productivity shortcut, than something required to select a file.

What was supper useful in making fuzzaldrin-plus was TONS of user report. That put a collective definition on what is intuitive behavior. Unfortunately there's no such thing now for recency / frequency boost.

Whatever we end up doing, I'm pretty sure the final form will be a narrow peak. For example autocomplete plus boost the score of result near insertion point, but it's mostly effective a few line before and after the cursor.

For fuzzy finder, I'm thinking it's possible to boost a few file among the recent / frequent files. Keyword being a few. If we try to be smart about date, but user forget he used that file, it'll just appear random.

As for the technical side I had a brain dump not too long ago on managing frequency count https://github.com/wincent/command-t/issues/165#issuecomment-143500356

[jeancroy]

Would something like that make sens ?

1. Initial screen is filled with promoted results. (Frequent and/or recent) Alphabetical results are added as needed to fill the visible list.
2. Promoted result have a bonus such that typing first char of query to select result will not make it jump from first to last.
3. Bonus is set such as valid result (non zero score) are artificially kept in the race up to about 3-4 character typed.
4. Pass that point the bonus (still the same from step 2-4) is mostly useful to overcome minor score difference (such as folder depth & overall path length). Nothing prevent the promoted result to appear first on its own merit. It's not impossible either that bonus make the difference between first and second place if they are close.

I'm talking from the POV of fuzzaldrin-plus where score grow with number of character typed. In such a case a constant bonus will range from important to not so much as more character are typed. (that sentence is true for both multiplicative or additive bonus)

I'm tempted to use this as backstory. Aka the user search for notification in a sea of notification related file. User could be more specific in query, but pointing to a recent / frequent file is still an user friendly thing to do.

[calebmeyer]

A few things which I think should give a recent-based bonus:

• An open, non-foreground tab (this allows for quick switch between tabs using fuzzy finder)
• A tab that was closed during this session (since the last time you closed atom)
• Any file that was edited recently, with more weight given to those within the last few hours, less weight for last few days, and no weight over maybe 3 days of inactivity. (The reason I say edited and not opened is that sometimes I open the wrong file, and wouldn't want that to improve its score)

I also really like the idea of a frequency based bonus. If atom can remember how many times I've opened application_controller.rb, it can promote it above application.rb when I type appcon.

[jeancroy]

I also really like the idea of a frequency based bonus. If atom can remember how many times I've opened application_controller.rb, it can promote it above application.rb when I type appcon.

I think it should already be the case. Are you using the alternate scoring ?

[calebmeyer]

I am, and it is, but what if application.rb were the more common one? I picked a bad example, but I do still run into this occasionally.

[jeancroy]

From a design standpoint example of the problem we are trying to solve is very useful. For example typing 'app' somehow prefering 'application_controller.rb' to 'application.rb'

but I do still run into this occasionally

very interested to hear about such user stories.

[lee-dohm]

BTW, the Slack engineering blog recently posted an article about how they optimized the channel switcher in Slack and included a "frecency" algorithm in it.

[juanmirocks]

My 2 cents: when the best match has a filename that is the same for other found files (e.g. when having multiple projects with same/similar files), just return the last accessed one.

From my view, I do not think this is against anybody's expectations. Please correct me if I'm wrong.

(This sorting algorithm should be very simple to implement and requires no extra weighting magic)

[calebmeyer]

@juanmirocks I can see where this algorithm would give me not the best result.

Let's say I'm working on a ruby project. I make some changes to the Gemfile (the dependencies file) in my project, but then have to switch gears. So I add another (related) project to the workspace. I open up a few files for project 2. Then I use the fuzzy finder to search for Gemfile.

What you propose would have the most recently accessed Gemfile show up first in the list. However, I've switched to working on the second project, and would like to see the Gemfile for the project I've worked in most recently.

I don't think there's a best answer for this case. Sometimes I'll want to refer back to project 1's Gemfile, sometimes I'll want to move on to project 2's Gemfile. The problem only gets worse if you have a top level folder for all the projects you work on and you open that at the start of your day.

[juanmirocks]

@calebmeyer I see your point. I don't know if the Atom API records the access date of the last accessed project...

Nonetheless, I still see as either your proposition or yours more sensible than the current one. The current approach pretty much seems random when the match is just a filename (and not its directory path), which I guess is very common. If that's the case, currently, the shown order is... what? I see no logic in that.

So giving a more sensible to same-filename matches makes sense to me. Either my proposition, yours, or both or other simple ways via configuration. I'm very much willing to submit a pull change with this. It would solve me lots of time in finding my files.

[mikegazdag]

Are we not able to implement a “Frecent” (frequent and recent) method like z does?