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* det...@die-offenbachs.de
_______________________________________________ Eric mailing list Eric@riverbankcomputing.com https://www.riverbankcomputing.com/mailman/listinfo/eric
