<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Mike C. Fletcher schrieb am 16.05.2016
um 17:04:<br>
</div>
<blockquote cite="mid:5739E182.5020402@vrplumber.com" type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">On 2016-05-16 09:40 AM, Tobias Rzepka
wrote:<br>
</div>
<blockquote
cite="mid:b373348c-f99e-42ed-a3e0-64ad4fbf98cf@gmail.com"
type="cite">
<p>Hello Mike,</p>
<p>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. <br>
</p>
<p>Mike and Detlev: What do you think about it?<br>
</p>
</blockquote>
<br>
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.<br>
<br>
<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:<br>
<br>
File "/usr/lib/python2.7/dist-packages/pkg_resources.py",
line 2363, in load_entry_point<br>
<br>
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.<br>
<br>
Always-interested-to-hear-of-a-new-use-case, though, ly-yrs,<br>
Mike<br>
<br>
</blockquote>
Hello Mike,<br>
<br>
I wasn't aware of the CTRL-ALT-F dialog. Typically I use
CTRL-SHIFT-F, but that's for finding something in files. So you are
right, that adding a line number would make no sense and the CTRL-G
isn't the right place... <br>
But that is what I had in mind:<br>
If it's a line number goto to that line (current file),<br>
if it's a method, function or class, open the file if not already
open and jump to the definition and<br>
if it's a filename just open the file (maybe with line number jump
to it ;-)<br>
<br>
So it would be a powerful goto dialog and your solution is relative
near I think.<br>
<br>
I like your solution for finding files in the project. But I think
to find files not in the project (maybe e.g. in sys.path) would be a
useful feature. Maybe a choice to os.walk a path instead of
"self.project.pdata.get" would do the trick...<br>
<br>
Two little things:<br>
Filename and path has to be exchanged in the UI and the ESC doesn't
work if you leave the input box (e.g. if you select with the mouse
but want to close the dialog with ESC). <br>
<br>
Tobias<br>
<br>
<blockquote cite="mid:5739E182.5020402@vrplumber.com" type="cite">
<blockquote
cite="mid:b373348c-f99e-42ed-a3e0-64ad4fbf98cf@gmail.com"
type="cite">
<p> </p>
Mike C. Fletcher schrieb am 16.05.2016 um 04:07:<br>
<blockquote cite="mid:57392B6B.3000405@vrplumber.com"
type="cite">
<div class="moz-cite-prefix">On 2016-05-14 06:06 AM, Detlev
Offenbach wrote:<br>
</div>
<blockquote
cite="mid:3a9d242a-918d-dcf0-2340-a0fa181318a4@die-offenbachs.de"
type="cite">
<p>Hi Mike,</p>
<p> </p>
<p>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.</p>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
Basic functionality:<br>
<br>
* space-separated search terms<br>
* finds that subset of items which have the most matches for
the search terms<br>
* 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)<br>
* provides key-bindings for enter (select current), escape
(cancel navigation) and up/down (select previous/next match in
the list)<br>
<br>
I've pushed the code up on BitBucket so you can pull from
there if you're interested in the functionality.<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bitbucket.org/mcfletch/eric/overview">https://bitbucket.org/mcfletch/eric/overview</a><br>
<br>
Take care, and thanks,<br>
Mike<br>
<br>
<blockquote
cite="mid:3a9d242a-918d-dcf0-2340-a0fa181318a4@die-offenbachs.de"
type="cite">Am 13.05.2016 um 22:26 schrieb Mike C. Fletcher:<br>
<blockquote cite="mid:5736387D.5010601@vrplumber.com"
type="cite">
<div class="moz-cite-prefix">On 2016-05-06 12:26 PM,
Detlev Offenbach wrote:<br>
</div>
<blockquote cite="mid:54170821.nth6ERysSY@saturn"
type="cite">
<meta name="qrichtext" content="1">
<p>Hi Mike,</p>
<p> </p>
<p>sounds like a great idea. How about contributing the
suggested modifications?</p>
<p> </p>
<p>Maybe somebody else is interested, in case Mike can't
do it?</p>
</blockquote>
<br>
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.<br>
<br>
Anyway, just wanted to avoid someone duplicating the work.
Take care,<br>
Mike<br>
<br>
<blockquote cite="mid:54170821.nth6ERysSY@saturn"
type="cite">
<p> </p>
<p>Detlev</p>
<p> </p>
<p>On Friday 06 May 2016, 12:07:44 Mike C. Fletcher
wrote:</p>
<p>> Hi Detlev (and everyone else),</p>
<p>> </p>
<p>> There's a feature I keep seeing in Atom and
other IDEs that is *really*</p>
<p>> helpful for jumping around in larger (10,000+
file) projects. It's a</p>
<p>> quick-file-search-and-open dialog. Basically
it's the functionality in</p>
<p>> File | Search File, but modelled as a
speed-optimized keyboard-centric</p>
<p>> searching/winnowing process.</p>
<p>> </p>
<p>> That is, you pop up the dialog with a
key-sequence and start typing</p>
<p>> (fragments from) the name of the file, so, for
instance, if I wanted to</p>
<p>> find "subproject/subproject/moo/models.py" I
would type something like this:</p>
<p>> </p>
<p>> ctrl-alt-f</p>
<p>> moo models subp</p>
<p>> <down> (to select the second match)</p>
<p>> <enter></p>
<p>> </p>
<p>> The search results would update as I typed "moo"
to have all files with</p>
<p>> the substring "moo" in their paths (with those
that have moo as a full</p>
<p>> path component sorted first, hopefully), then
when I start typing</p>
<p>> "models" would further restrict the set to those
items that contain both</p>
<p>> moo and models, and when I start typing
subp(roject) the search set gets</p>
<p>> down to 1-2 entries and I just select the entry
with the arrows and hit</p>
<p>> enter (again, without leaving the search box or
using the mouse).</p>
<p>> </p>
<p>> When results are displayed, the first item is
always selected, and</p>
<p>> hitting <enter> opens it, while up/down
arrows select other entries</p>
<p>> (again, without needing to switch focus from the
search box).</p>
<p>> </p>
<p>> The changes from current File Search suggested
are:</p>
<p>> </p>
<p>> * don't require file extension filtering</p>
<p>> o particularly when you have a *lot* of
no-file-extension files</p>
<p>> that restriction isn't all that useful</p>
<p>> o if the file-extension widget is empty, ignore
it</p>
<p>> * do simple sub-string matching on the set of
file-paths known to the</p>
<p>> project</p>
<p>> o do *not* require a full-name match on the
terms, but *rank*</p>
<p>> those result higher</p>
<p>> + allow e.g. "subproject/moo" to find everything
that has that</p>
<p>> sequence of characters in its path</p>
<p>> o this should likely be done on in-memory
structures only, *not*</p>
<p>> on the file system</p>
<p>> * treat space-delimited fragments as AND'd
search terms</p>
<p>> o again, ease of typing being the rationale
here, not something</p>
<p>> involved</p>
<p>> * allow hitting <up> and <down> to
change the selected item from the</p>
<p>> search box</p>
<p>> * allow hitting <enter> in the search box
to open the</p>
<p>> currently-selected file</p>
<p>> </p>
<p>> Nice enhancements:</p>
<p>> </p>
<p>> * sort results based on relevance ranking
(optional) so e.g. having a</p>
<p>> full path-unit == to a search term sorts before
having it as a</p>
<p>> sub-string of a path unit</p>
<p>> * if there are no matches (or less than a
threshold, such as a full</p>
<p>> screen of results), use fuzzy-matching (soundex,
ledit distance,</p>
<p>> etc) to try to find other possible matches
(always sorted below</p>
<p>> absolute matches)</p>
<p>> * as you type, do autocomplete on the path
fragments we know, so "sub"</p>
<p>> would autocomplete to the longest common
fragment that starts with</p>
<p>> "sub" (a-la bash or similar shell)</p>
<p>> </p>
<p>> With that done, we could also do the following:</p>
<p>> </p>
<p>> * on an import statement, launching file-search
could pre-populate</p>
<p>> with the import name (and with "from" imports,
the upper level</p>
<p>> module, with . translated to /)</p>
<p>> * on other fragments of code, launching
file-search could pre-populate</p>
<p>> with the current token</p>
<p>> </p>
<p>> Anyway, this is just a suggestion, and feel free
to say no.</p>
<p>> </p>
<p>> Thanks for all the great work on Eric,</p>
<p>> Mike -- </p>
<p><span>Detlev Offenbach</span></p>
<p><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:detlev@die-offenbachs.de">detlev@die-offenbachs.de</a></p>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
--
Detlev Offenbach
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:detlev@die-offenbachs.de">detlev@die-offenbachs.de</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Eric mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Eric@riverbankcomputing.com">Eric@riverbankcomputing.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.riverbankcomputing.com/mailman/listinfo/eric">https://www.riverbankcomputing.com/mailman/listinfo/eric</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>