[wingide-users] Feature request: contextual search or "close to" search operator

Yarko Tymciurak yarkot at uchicago.edu
Thu Oct 17 13:53:48 MDT 2013


On Thu, Oct 17, 2013 at 2:50 PM, Yarko Tymciurak <yarkot at uchicago.edu>wrote:

>
>
>
> On Thu, Oct 17, 2013 at 2:09 PM, Yarko Tymciurak <yarkot at uchicago.edu>wrote:
>
>>
>> On Oct 17, 2013, at 12:41 PM, Wingware Support <support at wingware.com>
>> wrote:
>>
>> > Anthony Floyd wrote:
>> >> Something I'd love to see in Wing: contextual search.
>> >>
>> >> Often I'll want to search for Term A but only when it's within the
>> >> same line or n lines of Term B. Sort of like a "close to" operator.
>> >>
>> >> Our main codebase is nearing 300k lines of Python, and keeping track
>> >> of where everything is has become challenging. But sometimes a "Search
>> >> in Files" returns way too many hits. A contextual search would go a
>> >> long way in helping.
>> >
>> > It's not quite the same thing but in Wing 5 you can create a File Set
>> from the set of files in the Search in Files result area, using the Name
>> Result File Set item in the Options menu, then do another search on that
>> file set by selecting it from the Look In menu. So "close to" is defined as
>> "in the same file", which may not be fine grained enough, but I thought it
>> might help in some cases.
>>
>>
>> Just sharing the thoughts this triggered as I read this:
>>
>> Two things reminiscent:
>>
>>   - xpath selectors, or perhaps even more:  cssselectors;
>>   - unified diff contexts (the ability to set the window size);
>>
>> It occurs that the externally maintained and referenced "tree" (thinking
>> in XML terms) Stephan referred to is file-space.
>>
>> W/o parsing to accomplish something like cssselector specificity  (i.e.
>> "only find "foo" in function contexts"),
>> but keeping w/ the concept of trees and the simplicity of unified diff
>> windows, I could imagine some not-too-complicated
>> plugin to hold a list of the last search nodes (file:line), and applying
>> a "Line Set" result, similar to the File Set result
>> capture, and then performing a search within a window (line) size of that
>> (referable a +/- set, e.g. a window of +/-10 is
>> (+10, -10), so you can imagine (+10, -0) as well).
>>
>> It seems like you'd need:
>>
>> - a search-result list held somewhere;
>> - a way to limit search across files to line numbers;
>> - a way to specify a search with the first list, calculated as a range by
>> the window.
>>
>> Seems conceptually doable (and I think, as I think of it, I like it -
>> though I wonder how useful it would be in practice,
>> over the "File Set" model).   Also - thinking back to cssselectors - I
>> can imagine a plugin that lets you do several levels,
>> sequentially, so you could accomplish the cssselctor-like equivalent of
>> "foo > bar(-0,+30) > what_I_want", where
>> no window implies file-sized window.
>>
>
> ... so to continue that (since I'm liking thinking about this):
>
> that nested search:    "foo > bar(-0,+30) > what_I_want"
> would read / operate like:
>
> in the current File Set (the default Match Set),  find instances of "foo";
> { implied: save file:line list of that Match Set };
> in the current Match Set, search a window of (0, 30) for bar;
> { implied: save file:line list of that Match Set };
> in the File Set of the current Match Set (since no window applied, entire
> file implied), find "what_I_want"
>
> As I read the sentences, I suppose something like this might be more
> suggestive, but this is minor:
>
> foo > {-0,+30}bar > what_I_want
>
> (reminiscent of RE repeat ranges)
>
> I wouldn't associate the range with the last search target, as that window
> could usefully vary with the next target search - it should be a
> characteristic
> of the current search, applied to the last file:line set (not a
> characteristic
> of the last Match Result set).
>
> This _is_ fun! :-)
>


The obvious "problem" of maintaining the file:line number Set up-to-date
goes away if you don't keep it - that is, this is transitory, only valid for
the operation of a search.

I don't imagine the performance would be too horrid (but haven't really
thought about it much).


>
>
>> Fun concept!
>>
>> >
>> > --
>> > Stephan Deibel
>> > Wingware | Python IDE
>> > Advancing Software Development
>> >
>> > www.wingware.com
>> > _________________________________________________
>> > Wing IDE users list
>> > http://wingware.com/lists/wingide
>>
>> _________________________________________________
>> Wing IDE users list
>> http://wingware.com/lists/wingide
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/wingide-users/attachments/20131017/7055b29b/attachment.html>


More information about the wingide-users mailing list