Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
Hi Mike, I integrated your new dialog into eric6 (default branch). However, as it search in files of the current project I put it into the 'Project' package. I fixed a few issues (code bugs, code style issues) and added the case insensitive search as a fall back. Thanks for contributing this code. Regards, Detlev On Monday 16 May 2016, 11:04:34 Mike C. Fletcher wrote: > 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 appname models 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. > > (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* > > ___ Eric mailing list Eric@riverbankcomputing.com https://www.riverbankcomputing.com/mailman/listinfo/eric
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
On 2016-05-16 03:55 PM, Tobias Rzepka wrote: ... Hello Mike, 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... But that is what I had in mind: If it's a line number goto to that line (current file), if it's a method, function or class, open the file if not already open and jump to the definition and if it's a filename just open the file (maybe with line number jump to it ;-) So it would be a powerful goto dialog and your solution is relative near I think. 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... You'll note that the original dialog did have the "search sys.path" behaviour. I left that out of the revised dialog because my focus is on being to able to jump around quickly in large projects. Doing a file-system walk on the entirety of sys.path is likely to cause issues for users with lots of very big projects. My (new) laptop (with a fast SSD) does a sys.path walk in around .2s, because it doesn't have much software installed (but that is still pretty slow for something you want to do between keystrokes). For comparison, my (powerful, but older, and using a spinning disk) workstation takes close to a minute just to walk sys.path and winds up with 365,000+ files in the search set. That's just kind of pointless as a search set probably 99% of the time (on Debian systems you wind up with an enormous amount of system software on sys.path). You could cache that, of course, but a minute of searching/indexing is... heavy, and the index would need to be re-scanned periodically. If you wanted to "find a class of name X" you'd have to have a source-code-content index and use that in the goto dialog. I don't *believe* we have a generic indexing mechanism in Eric yet to make that work cleanly. You could easily do heuristics such as looking for imports in the files and figuring out the most likely modules/packages in which to search, basically "adding to the search set" for just those packages your code actually imports. You could lean on the existing completion implementations to do some contextualized jumping (though I think most of them will only index code in your project), but my focus so far has been on getting the "jump to a known file" working cleanly. If you'd like to work on something more advanced, I'm guessing Detlev might be interested :D BTW, if you *do* want to work on it, cloning off of Detlev's machine is rather slow (at least from Canada), feel free to use the Bitbucket mirror I've set up. 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). Thanks. Both fixed on the version now up on bitbucket. https://bitbucket.org/mcfletch/eric I also make the search box re-focus when you hit the keybinding so that you can immediately start typing without worrying about whether you selected something else in the dialog previously. Other than possibly adding code to auto-populate the search with current-line-of-code content I'm relatively happy with the dialog for jumping around my large projects. I still wind up using the project tree here and there when I've forgotten what the name of a module or file was, but for the most part I now simply direct-jump with a file-search. Take care, 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
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
Mike C. Fletcher schrieb am 16.05.2016 um 17:04: 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 appname models 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. (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 Hello Mike, 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... But that is what I had in mind: If it's a line number goto to that line (current file), if it's a method, function or class, open the file if not already open and jump to the definition and if it's a filename just open the file (maybe with line number jump to it ;-) So it would be a powerful goto dialog and your solution is relative near I think. 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... Two little things: 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). Tobias 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
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
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 appname models 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. (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 > (to select the second match) > > > 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 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
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
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? Tobias 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 > (to select the second match) > > > 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
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
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 > (to select the second match) > > > 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 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 and to change the selected item from the > search box > * allow hitting 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
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
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 > (to select the second match) > > > 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 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 and to change the selected item from the > search box > * allow hitting 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 -- -- Detlev Offenbach det...@die-offenbachs.de ___ Eric mailing list Eric@riverbankcomputing.com https://www.riverbankcomputing.com/mailman/listinfo/eric
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
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 > (to select the second match) > > > 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 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 and to change the selected item from the > search box > * allow hitting 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
Re: [Eric] Feature request/suggestion (feature modification suggestion, really)
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 > (to select the second match) > > > 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 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 and to change the selected item from the > search box > * allow hitting 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
