Detlev
On Friday 06 May 2016, 12:07:44 Mike C. Fletcher
wrote:
> Hi Detlev (and everyone else),
>
> There's a feature I keep seeing in Atom and
other IDEs that is *really*
> helpful for jumping around in larger (10,000+
file) projects. It's a
> quick-file-search-and-open dialog. Basically
it's the functionality in
> File | Search File, but modelled as a
speed-optimized keyboard-centric
> searching/winnowing process.
>
> That is, you pop up the dialog with a
key-sequence and start typing
> (fragments from) the name of the file, so, for
instance, if I wanted to
> find "subproject/subproject/moo/models.py" I
would type something like this:
>
> ctrl-alt-f
> moo models subp
> <down> (to select the second match)
> <enter>
>
> The search results would update as I typed "moo"
to have all files with
> the substring "moo" in their paths (with those
that have moo as a full
> path component sorted first, hopefully), then
when I start typing
> "models" would further restrict the set to those
items that contain both
> moo and models, and when I start typing
subp(roject) the search set gets
> down to 1-2 entries and I just select the entry
with the arrows and hit
> enter (again, without leaving the search box or
using the mouse).
>
> When results are displayed, the first item is
always selected, and
> hitting <enter> opens it, while up/down
arrows select other entries
> (again, without needing to switch focus from the
search box).
>
> The changes from current File Search suggested
are:
>
> * don't require file extension filtering
> o particularly when you have a *lot* of
no-file-extension files
> that restriction isn't all that useful
> o if the file-extension widget is empty, ignore
it
> * do simple sub-string matching on the set of
file-paths known to the
> project
> o do *not* require a full-name match on the
terms, but *rank*
> those result higher
> + allow e.g. "subproject/moo" to find everything
that has that
> sequence of characters in its path
> o this should likely be done on in-memory
structures only, *not*
> on the file system
> * treat space-delimited fragments as AND'd
search terms
> o again, ease of typing being the rationale
here, not something
> involved
> * allow hitting <up> and <down> to
change the selected item from the
> search box
> * allow hitting <enter> in the search box
to open the
> currently-selected file
>
> Nice enhancements:
>
> * sort results based on relevance ranking
(optional) so e.g. having a
> full path-unit == to a search term sorts before
having it as a
> sub-string of a path unit
> * if there are no matches (or less than a
threshold, such as a full
> screen of results), use fuzzy-matching (soundex,
ledit distance,
> etc) to try to find other possible matches
(always sorted below
> absolute matches)
> * as you type, do autocomplete on the path
fragments we know, so "sub"
> would autocomplete to the longest common
fragment that starts with
> "sub" (a-la bash or similar shell)
>
> With that done, we could also do the following:
>
> * on an import statement, launching file-search
could pre-populate
> with the import name (and with "from" imports,
the upper level
> module, with . translated to /)
> * on other fragments of code, launching
file-search could pre-populate
> with the current token
>
> Anyway, this is just a suggestion, and feel free
to say no.
>
> Thanks for all the great work on Eric,
> Mike --
Detlev Offenbach
[email protected]
