Is the fuzzy finder limited to 10 files?


#1

This problem seems so basic that I am convinced I must have missed a setting, or even just a keyboard press. If I have, my apologies. I really have tried searching for information already online, but without luck.

When I use Control+P to access the fuzzy finder, and enter search text, only ten results are listed. I can scroll through the brief list, and open the files, but even when I know many more matching files exist, they are not listed.

Is this as designed? Is it documented? How might I make all the matching files appear?

I’m using Atom on a Windows 10 machine.

Any advice gratefully received,

Manny


#2

Yes I believe this is expected and it’s been that way for a while?

I remember reading issues referencing this behavior but can’t find any off-hand right now - doesn’t seem to be explicitly documented in the Flight Manual (https://flight-manual.atom.io/getting-started/sections/atom-basics/#opening-a-file-in-a-project) but we would take a look at a pull request to add this detail.


#3

Thank you for taking the trouble to reply. It’s good to know that I wasn’t simply missing something obvious.

  It seemed clear to me that, in practice, there was some kind of limit, but I didn't know if this was just (so to speak) a limited "first page" of results, allowing me to scroll through further pages using some keypress, or if somewhere in the editor's settings, or those of the package, the limit could be removed (or even just changed), or if the limit was fixed and I'd merely missed a message or piece of documentation telling me so.

  What compounded the confusion was that other editors in the identifiable family which seems to have grown up with similar look and feel - Sublime, MS VCS, Light Table, Cudatext, and so on - don't apply a limit to their finder equivalents: so those of us converting from one of these will not be expecting one.

  I'm guessing the limit exists for some sort of performance reason? That's reasonable of course, but there may be ways to at least warn the user, if not apply a slightly more flexible policy. In case they are of any interest, I'd offer the following suggestions:
  1. Document the limit.

    Surely essential? If you’re documenting a search facility which will return 10 results at most, surely it’s not excessive to tell us “This will return 10 results at most.”

    True: it has occasionally been know that a user didn’t consult the manual… but surely all the more reason that when one of us does actually RTFM, it should help as much as possible?

  2. Warn users if the limit has been reached.

    If there were many results of which only the best 10 are being shown, warn us. Just a line above the list saying (say) “Best 10 matches:”, so we won’t be misled into thinking these are the only matches, or confused if the one we were expecting isn’t there.

    Be kind.

    1. Make the limit configurable.

    Offer a package setting to change the limit, and ideally one which accepts a 0 to disable it altogether.

    I know… the limit is probably there for a reason. But we’re grown ups - warn us. “Setting this limit above 10 may make searches VERY slow, crash the editor, set fire to your computer, or affect your healthcare entitlements.”

    While the limit may often be what people want - by all means leave it as the default - it may not always be wanted, or even necessary. A quicker system, or smaller project, might safely benefit from an option to increase it.

    These suggestions aren’t specifically addressed to you, by the way. I’m not sure of the mechanisms by which work on Atom is planned, and so I’m merely offering them in the vague hope that they are seen by whomever they need be seen by.

    Once again, your answer is useful in itself and most gratefully received.

    Manny