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
_______________________________________________
Eric mailing list
Eric@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/eric
