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

[Detlev Offenbach]

Hi Mike,

sounds like a great idea. How about contributing the suggested modifications?

Maybe somebody else is interested, in case Mike can't do it?

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*
detlev at die-offenbachs.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/eric/attachments/20160506/5ea5f76f/attachment-0001.html>