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

[Mike C. Fletcher]

On 2016-05-16 09:40 AM, Tobias Rzepka wrote:
>
> Hello Mike,
>
> sounds for me like a great improvement. Even I didn't checked your 
> implementation yet, I would suggest to put it onto CTRL-G. Actually 
> it's goto line (on Windows), but it should be easy, to include the 
> goto line into the new functionality if not already done. So the 
> search in files dialog would still coexist, e.g. to search all files, 
> not only code.
>
> Mike and Detlev: What do you think about it?
>

To be clear, this is a dialog to find by file-name, not by file content. 
That is, you want to find the "models.py" file from "appname" quickly 
you do <ctrl-alt-f> appname models <enter> and you've opened that file. 
I'd be very hesitant to add "jump to line" to that unless there was a 
strong use-case.

<ctrl-g> (goto line) is, in my experience, far too heavily used to be 
made more complex unless we've got a real need for it (e.g. I could 
imagine having a search mode that took a copy-pasted traceback line:

       File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 
2363, in load_entry_point

and directly jumped to the file and line indicated). But I can't think 
of many other use cases where I'm trying to find a file by name and also 
happen to explicitly know the line number to which I want to jump in 
that target file.

Always-interested-to-hear-of-a-new-use-case, though, ly-yrs,
Mike

> Mike C. Fletcher schrieb am 16.05.2016 um 04:07:
>> 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
>>
>>
>>
>> _______________________________________________
>> Eric mailing list
>> Eric at riverbankcomputing.com
>> https://www.riverbankcomputing.com/mailman/listinfo/eric
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/eric/attachments/20160516/8bc3316e/attachment-0001.html>