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

[Detlev Offenbach]

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.

Detlev


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/20160514/2e7b470d/attachment-0001.html>