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

[Mike C. Fletcher]

On 2016-05-14 06:06 AM, Detlev Offenbach wrote:
>
> Hi Mike,
>
> thanks for letting us know. Please make sure you base your work on the 
> default branch because the 6_1_x brand (aka eric 6.1) is feature 
> frozen. It just receives bug fixes.
>

Okay, so I've got it working to the level where I'm pretty satisfied 
with the speed/utility of the find-file operation (note: haven't done 
any heavy hacking with it yet, so it could be I'll find other bits that 
would be useful).

I've hooked it up for now to replace the FindFileNameDialog, as I only 
ever use the "Find in Project" version. It may be that it should be 
hooked up under a different key-binding/menu-item if you decide to pull 
it into the project. I built this dialog as a separate module/form 
(though it's just based on the FindFileNameDialog), as the functionality 
is somewhat different than the original dialog.

Basic functionality:

* space-separated search terms
* finds that subset of items which have the most matches for the search 
terms
* sorts the subset based on the terms matching in-order, then on the 
most-recent modification time (this actually hits the file system with a 
stat-per-file, but even on huge projects this doesn't seem to cause a 
noticeable delay)
* provides key-bindings for enter (select current), escape (cancel 
navigation) and up/down (select previous/next match in the list)

I've pushed the code up on BitBucket so you can pull from there if 
you're interested in the functionality.

https://bitbucket.org/mcfletch/eric/overview

Take care, and thanks,
Mike

> Am 13.05.2016 um 22:26 schrieb Mike C. Fletcher:
>> On 2016-05-06 12:26 PM, Detlev Offenbach wrote:
>>>
>>> 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?
>>>
>>
>> I've started into work on it... I've got a hacked-up proof of concept 
>> dialog that does the basics but still needs work to get key-bindings 
>> and the like worked out.
>>
>> Anyway, just wanted to avoid someone duplicating the work. Take care,
>> Mike
>>
>>> 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
>>>
>>
>
> -- 
> --
> Detlev Offenbach
> detlev at die-offenbachs.de

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