<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Detlev (and everyone else),<br>
<br>
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.<br>
<br>
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:<br>
<br>
ctrl-alt-f<br>
moo models subp<br>
<down> (to select the second match)<br>
<enter><br>
<br>
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).<br>
<br>
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).<br>
<br>
The changes from current File Search suggested are:<br>
<ul>
<li>don't require file extension filtering</li>
<ul>
<li>particularly when you have a *lot* of no-file-extension
files that restriction isn't all that useful</li>
<li>if the file-extension widget is empty, ignore it<br>
</li>
</ul>
<li>do simple sub-string matching on the set of file-paths known
to the project</li>
<ul>
<li>do *not* require a full-name match on the terms, but *rank*
those result higher</li>
<ul>
<li>allow e.g. "subproject/moo" to find everything that has
that sequence of characters in its path<br>
</li>
</ul>
<li>this should likely be done on in-memory structures only,
*not* on the file system</li>
</ul>
<li>treat space-delimited fragments as AND'd search terms</li>
<ul>
<li>again, ease of typing being the rationale here, not
something involved<br>
</li>
</ul>
<li>allow hitting <up> and <down> to change the
selected item from the search box</li>
<li>allow hitting <enter> in the search box to open the
currently-selected file</li>
</ul>
<p>Nice enhancements:<br>
</p>
<ul>
<li>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</li>
<li>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)</li>
<li>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)<br>
</li>
</ul>
<p>With that done, we could also do the following:<br>
</p>
<ul>
<li>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 /)</li>
<li>on other fragments of code, launching file-search could
pre-populate with the current token</li>
</ul>
<p>Anyway, this is just a suggestion, and feel free to say no.<br>
</p>
<p>Thanks for all the great work on Eric,<br>
Mike<br>
</p>
</body>
</html>