[Eric] Feature request/suggestion (feature modification suggestion, really)

[Mike C. Fletcher]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/eric/attachments/20160506/b2c11d74/attachment.html>