From: Shlomy R. <sre...@gm...> - 2008-09-29 19:04:47
|
Hi, I'd like to add a capability to the hypersearch results dockable, to filter out results based on various criteria, such as path globs or substrings of the results. Of course, these filters would preferably be part of the search itself, and not the search results, but often I run some project-wide search without thinking of these things, and later I see many irrelevant results and would like to filter them out rather than run a new search with these filters. One option to implement this is to have some "filter" dropdown in the hypersearch results dockable, which would allow using one of several saved filters, or alternatively open a dialog to create a new filter. Another option, less intuitive but most powerful, is to have the ability to send the hypersearch results in some specific format to a new buffer, and also be able to read it back from the buffer into the hypersearch results, so that one can "export" the results to a buffer, make any changes one likes (like remove irrelevant results) in the buffer, and then "import" the results back to the hypersearch results dockable. Any recommendations? Shlomy |
From: Sarah C. <cra...@gm...> - 2008-09-29 19:08:47
|
Wow, that sounds like a great feature. I have done things like that manually by exporting my search results to a buffer and searching on that buffer, but this would be much better. On Mon, Sep 29, 2008 at 2:04 PM, Shlomy Reinstein <sre...@gm...>wrote: > Hi, > > I'd like to add a capability to the hypersearch results dockable, to > filter out results based on various criteria, such as path globs or > substrings of the results. Of course, these filters would preferably > be part of the search itself, and not the search results, but often I > run some project-wide search without thinking of these things, and > later I see many irrelevant results and would like to filter them out > rather than run a new search with these filters. > One option to implement this is to have some "filter" dropdown in the > hypersearch results dockable, which would allow using one of several > saved filters, or alternatively open a dialog to create a new filter. > Another option, less intuitive but most powerful, is to have the > ability to send the hypersearch results in some specific format to a > new buffer, and also be able to read it back from the buffer into the > hypersearch results, so that one can "export" the results to a buffer, > make any changes one likes (like remove irrelevant results) in the > buffer, and then "import" the results back to the hypersearch results > dockable. > Any recommendations? > > Shlomy > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > |
From: Matthew G. <gi...@vo...> - 2008-09-29 20:21:21
|
Hi Shlomy, Take a look in the SideKick plugin (SideKickTree.java and FilteredTreeModel.java). I added some code to filter sidekick nodes, maybe the same filtering code could be used for this. The FilteredTreeModel I stole from LimeWire. I think the UI's for this filter and the SideKick filter should match. BTW, great idea, I'd use this a lot. _matt On Mon, Sep 29, 2008 at 3:04 PM, Shlomy Reinstein <sre...@gm...> wrote: > Hi, > > I'd like to add a capability to the hypersearch results dockable, to > filter out results based on various criteria, such as path globs or > substrings of the results. Of course, these filters would preferably > be part of the search itself, and not the search results, but often I > run some project-wide search without thinking of these things, and > later I see many irrelevant results and would like to filter them out > rather than run a new search with these filters. > One option to implement this is to have some "filter" dropdown in the > hypersearch results dockable, which would allow using one of several > saved filters, or alternatively open a dialog to create a new filter. > Another option, less intuitive but most powerful, is to have the > ability to send the hypersearch results in some specific format to a > new buffer, and also be able to read it back from the buffer into the > hypersearch results, so that one can "export" the results to a buffer, > make any changes one likes (like remove irrelevant results) in the > buffer, and then "import" the results back to the hypersearch results > dockable. > Any recommendations? > > Shlomy > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > |
From: Shlomy R. <sre...@gm...> - 2008-09-29 19:59:18
|
That's nice, but note that for SideKick, all nodes have the same meaning - they just cover some area of the buffer. In the case of hypersearch results - there are two node types: file paths and the lines of text. One should be able to filter by either of them, and the filter for one should not apply to the other. What about my suggestion to use an export/import feature (to/from a buffer)? Shlomy On Mon, Sep 29, 2008 at 9:32 PM, Matthew Gilbert <gi...@vo...> wrote: > Hi Shlomy, > > Take a look in the SideKick plugin (SideKickTree.java and > FilteredTreeModel.java). I added some code to filter sidekick nodes, > maybe the same filtering code could be used for this. The > FilteredTreeModel I stole from LimeWire. I think the UI's for this > filter and the SideKick filter should match. > > BTW, great idea, I'd use this a lot. > > _matt > > On Mon, Sep 29, 2008 at 3:04 PM, Shlomy Reinstein <sre...@gm...> wrote: >> Hi, >> >> I'd like to add a capability to the hypersearch results dockable, to >> filter out results based on various criteria, such as path globs or >> substrings of the results. Of course, these filters would preferably >> be part of the search itself, and not the search results, but often I >> run some project-wide search without thinking of these things, and >> later I see many irrelevant results and would like to filter them out >> rather than run a new search with these filters. >> One option to implement this is to have some "filter" dropdown in the >> hypersearch results dockable, which would allow using one of several >> saved filters, or alternatively open a dialog to create a new filter. >> Another option, less intuitive but most powerful, is to have the >> ability to send the hypersearch results in some specific format to a >> new buffer, and also be able to read it back from the buffer into the >> hypersearch results, so that one can "export" the results to a buffer, >> make any changes one likes (like remove irrelevant results) in the >> buffer, and then "import" the results back to the hypersearch results >> dockable. >> Any recommendations? >> >> Shlomy >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> > |
From: Shlomy R. <sre...@gm...> - 2008-09-29 20:50:37
|
One advantage that I did not mention of an export/import capability of the hypersearch results to/from a buffer is the ability to save the results in a file and load them any time later. You can store several sets of results to a file and load them later instead of searching again, and they would function as long as the locations saved have not moved (i.e. the files were not changed). This alone is not a good enough reason to use this technique for filtering the results. Maybe both techniques should be implemented - export/import and a filter button in the dockable. Shlomy On Mon, Sep 29, 2008 at 9:59 PM, Shlomy Reinstein <sre...@gm...> wrote: > That's nice, but note that for SideKick, all nodes have the same > meaning - they just cover some area of the buffer. In the case of > hypersearch results - there are two node types: file paths and the > lines of text. One should be able to filter by either of them, and the > filter for one should not apply to the other. > What about my suggestion to use an export/import feature (to/from a buffer)? > Shlomy > > On Mon, Sep 29, 2008 at 9:32 PM, Matthew Gilbert <gi...@vo...> wrote: >> Hi Shlomy, >> >> Take a look in the SideKick plugin (SideKickTree.java and >> FilteredTreeModel.java). I added some code to filter sidekick nodes, >> maybe the same filtering code could be used for this. The >> FilteredTreeModel I stole from LimeWire. I think the UI's for this >> filter and the SideKick filter should match. >> >> BTW, great idea, I'd use this a lot. >> >> _matt >> >> On Mon, Sep 29, 2008 at 3:04 PM, Shlomy Reinstein <sre...@gm...> wrote: >>> Hi, >>> >>> I'd like to add a capability to the hypersearch results dockable, to >>> filter out results based on various criteria, such as path globs or >>> substrings of the results. Of course, these filters would preferably >>> be part of the search itself, and not the search results, but often I >>> run some project-wide search without thinking of these things, and >>> later I see many irrelevant results and would like to filter them out >>> rather than run a new search with these filters. >>> One option to implement this is to have some "filter" dropdown in the >>> hypersearch results dockable, which would allow using one of several >>> saved filters, or alternatively open a dialog to create a new filter. >>> Another option, less intuitive but most powerful, is to have the >>> ability to send the hypersearch results in some specific format to a >>> new buffer, and also be able to read it back from the buffer into the >>> hypersearch results, so that one can "export" the results to a buffer, >>> make any changes one likes (like remove irrelevant results) in the >>> buffer, and then "import" the results back to the hypersearch results >>> dockable. >>> Any recommendations? >>> >>> Shlomy >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> -- >>> ----------------------------------------------- >>> jEdit Users' List >>> jEd...@li... >>> https://lists.sourceforge.net/lists/listinfo/jedit-users >>> >> > |
From: FORREST E. <for...@ad...> - 2008-09-29 20:34:45
|
The export to a file option is a good idea. I do this type of thing quite often when I'm studying debug log files. I'm not really sure what I'm looking for initially, so I arrive at a search filter through an iterative process. Most of the time, I want to see the filtered data in a separate file for easier viewing. I've been using the Extended Search Plugin for some time now. One of the things I really like about it is the ability to write a search node to a buffer. I will often write a hyper-search to a buffer, then perform an additional 'filtering' hyper-search on the new buffer. Forrest Sent from my desktop. > -----Original Message----- > From: Shlomy Reinstein [mailto:sre...@gm...] > Sent: Monday, September 29, 2008 2:59 PM > To: Matthew Gilbert > Cc: jedit-users > Subject: Re: [ jEdit-users ] Filtering hypersearch results > > That's nice, but note that for SideKick, all nodes have the > same meaning - they just cover some area of the buffer. In > the case of hypersearch results - there are two node types: > file paths and the lines of text. One should be able to > filter by either of them, and the filter for one should not > apply to the other. > What about my suggestion to use an export/import feature > (to/from a buffer)? > Shlomy > > On Mon, Sep 29, 2008 at 9:32 PM, Matthew Gilbert > <gi...@vo...> wrote: > > Hi Shlomy, > > > > Take a look in the SideKick plugin (SideKickTree.java and > > FilteredTreeModel.java). I added some code to filter > sidekick nodes, > > maybe the same filtering code could be used for this. The > > FilteredTreeModel I stole from LimeWire. I think the UI's for this > > filter and the SideKick filter should match. > > > > BTW, great idea, I'd use this a lot. > > > > _matt > > > > On Mon, Sep 29, 2008 at 3:04 PM, Shlomy Reinstein > <sre...@gm...> wrote: > >> Hi, > >> > >> I'd like to add a capability to the hypersearch results > dockable, to > >> filter out results based on various criteria, such as path > globs or > >> substrings of the results. Of course, these filters would > preferably > >> be part of the search itself, and not the search results, > but often I > >> run some project-wide search without thinking of these things, and > >> later I see many irrelevant results and would like to > filter them out > >> rather than run a new search with these filters. > >> One option to implement this is to have some "filter" > dropdown in the > >> hypersearch results dockable, which would allow using one > of several > >> saved filters, or alternatively open a dialog to create a > new filter. > >> Another option, less intuitive but most powerful, is to have the > >> ability to send the hypersearch results in some specific > format to a > >> new buffer, and also be able to read it back from the > buffer into the > >> hypersearch results, so that one can "export" the results to a > >> buffer, make any changes one likes (like remove irrelevant > results) > >> in the buffer, and then "import" the results back to the > hypersearch > >> results dockable. > >> Any recommendations? > >> > >> Shlomy > >> > >> > --------------------------------------------------------------------- > >> ---- This SF.Net email is sponsored by the Moblin Your Move > >> Developer's challenge Build the coolest Linux based > applications with > >> Moblin SDK & win great prizes Grand prize is a trip for two to an > >> Open Source event anywhere in the world > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> -- > >> ----------------------------------------------- > >> jEdit Users' List > >> jEd...@li... > >> https://lists.sourceforge.net/lists/listinfo/jedit-users > >> > > > > -------------------------------------------------------------- > ----------- > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge Build the coolest Linux based > applications with Moblin SDK & win great prizes Grand prize > is a trip for two to an Open Source event anywhere in the > world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > |
From: Matthew G. <gi...@vo...> - 2008-09-30 15:01:13
|
The SideKick filtering currently filters everything (leaf nodes and interior nodes). It's not ideal, but in my testing it usually gets me what I want and I don't have to mess with any settings. It could probably use an extra option to specify only leaf nodes. I think that would also work for hypersearch filtering. If an interior node passes, then all of its child nodes pass. That's how I would expect a filename filter to behave. With the extra option, you could then disable filename matches and filter only by the search results text. Adding this definitely wouldn't preclude the import/export stuff. There doesn't seem to be much overlap. On Mon, Sep 29, 2008 at 3:59 PM, Shlomy Reinstein <sre...@gm...> wrote: > That's nice, but note that for SideKick, all nodes have the same > meaning - they just cover some area of the buffer. In the case of > hypersearch results - there are two node types: file paths and the > lines of text. One should be able to filter by either of them, and the > filter for one should not apply to the other. > What about my suggestion to use an export/import feature (to/from a buffer)? > Shlomy > > On Mon, Sep 29, 2008 at 9:32 PM, Matthew Gilbert <gi...@vo...> wrote: >> Hi Shlomy, >> >> Take a look in the SideKick plugin (SideKickTree.java and >> FilteredTreeModel.java). I added some code to filter sidekick nodes, >> maybe the same filtering code could be used for this. The >> FilteredTreeModel I stole from LimeWire. I think the UI's for this >> filter and the SideKick filter should match. >> >> BTW, great idea, I'd use this a lot. >> >> _matt >> >> On Mon, Sep 29, 2008 at 3:04 PM, Shlomy Reinstein <sre...@gm...> wrote: >>> Hi, >>> >>> I'd like to add a capability to the hypersearch results dockable, to >>> filter out results based on various criteria, such as path globs or >>> substrings of the results. Of course, these filters would preferably >>> be part of the search itself, and not the search results, but often I >>> run some project-wide search without thinking of these things, and >>> later I see many irrelevant results and would like to filter them out >>> rather than run a new search with these filters. >>> One option to implement this is to have some "filter" dropdown in the >>> hypersearch results dockable, which would allow using one of several >>> saved filters, or alternatively open a dialog to create a new filter. >>> Another option, less intuitive but most powerful, is to have the >>> ability to send the hypersearch results in some specific format to a >>> new buffer, and also be able to read it back from the buffer into the >>> hypersearch results, so that one can "export" the results to a buffer, >>> make any changes one likes (like remove irrelevant results) in the >>> buffer, and then "import" the results back to the hypersearch results >>> dockable. >>> Any recommendations? >>> >>> Shlomy >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> -- >>> ----------------------------------------------- >>> jEdit Users' List >>> jEd...@li... >>> https://lists.sourceforge.net/lists/listinfo/jedit-users >>> >> > |
From: Shlomy R. <sre...@gm...> - 2008-09-30 15:47:05
|
For now, I have implemented the other method for filtering - export the search results to a buffer, then import it back (after making changes to the buffer, e.g. removing all lines that match some regexp). This has the added value of enabling persistence of search results. You can save the buffer with the exported results in a file, then load it back at any time and import again. I might still add a GUI for filtering, but filtering through a buffer is much more powerful than any GUI I may create. Shlomy On Tue, Sep 30, 2008 at 4:55 PM, Matthew Gilbert <gi...@vo...> wrote: > The SideKick filtering currently filters everything (leaf nodes and > interior nodes). It's not ideal, but in my testing it usually gets me > what I want and I don't have to mess with any settings. It could > probably use an extra option to specify only leaf nodes. I think that > would also work for hypersearch filtering. If an interior node passes, > then all of its child nodes pass. That's how I would expect a filename > filter to behave. With the extra option, you could then disable > filename matches and filter only by the search results text. Adding > this definitely wouldn't preclude the import/export stuff. There > doesn't seem to be much overlap. > > On Mon, Sep 29, 2008 at 3:59 PM, Shlomy Reinstein <sre...@gm...> wrote: >> That's nice, but note that for SideKick, all nodes have the same >> meaning - they just cover some area of the buffer. In the case of >> hypersearch results - there are two node types: file paths and the >> lines of text. One should be able to filter by either of them, and the >> filter for one should not apply to the other. >> What about my suggestion to use an export/import feature (to/from a buffer)? >> Shlomy >> >> On Mon, Sep 29, 2008 at 9:32 PM, Matthew Gilbert <gi...@vo...> wrote: >>> Hi Shlomy, >>> >>> Take a look in the SideKick plugin (SideKickTree.java and >>> FilteredTreeModel.java). I added some code to filter sidekick nodes, >>> maybe the same filtering code could be used for this. The >>> FilteredTreeModel I stole from LimeWire. I think the UI's for this >>> filter and the SideKick filter should match. >>> >>> BTW, great idea, I'd use this a lot. >>> >>> _matt >>> >>> On Mon, Sep 29, 2008 at 3:04 PM, Shlomy Reinstein <sre...@gm...> wrote: >>>> Hi, >>>> >>>> I'd like to add a capability to the hypersearch results dockable, to >>>> filter out results based on various criteria, such as path globs or >>>> substrings of the results. Of course, these filters would preferably >>>> be part of the search itself, and not the search results, but often I >>>> run some project-wide search without thinking of these things, and >>>> later I see many irrelevant results and would like to filter them out >>>> rather than run a new search with these filters. >>>> One option to implement this is to have some "filter" dropdown in the >>>> hypersearch results dockable, which would allow using one of several >>>> saved filters, or alternatively open a dialog to create a new filter. >>>> Another option, less intuitive but most powerful, is to have the >>>> ability to send the hypersearch results in some specific format to a >>>> new buffer, and also be able to read it back from the buffer into the >>>> hypersearch results, so that one can "export" the results to a buffer, >>>> make any changes one likes (like remove irrelevant results) in the >>>> buffer, and then "import" the results back to the hypersearch results >>>> dockable. >>>> Any recommendations? >>>> >>>> Shlomy >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> -- >>>> ----------------------------------------------- >>>> jEdit Users' List >>>> jEd...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jedit-users >>>> >>> >> > |
From: Kazutoshi S. <k_s...@f2...> - 2008-09-30 17:40:39
|
Shlomy Reinstein wrote: > I'd like to add a capability to the hypersearch results dockable, to > filter out results based on various criteria, such as path globs or (snip) > Any recommendations? I want you to sweep existing bugs instead of implementing and testing a new feature. Since sweeping bugs can be done by not only developers but also users, I think this is good to say on jedit-users instead of jedit-devel, and also this is a good time to say this because you looks seeking something good to do for jEdit. I mean "sweeping bugs" as reproducing the bugs and apply the result to the bug. The result can be changing the status appropriately, or just adding a comment saying it was not reproducible in a environment. In latter case, changing the status to Pending in the same time with asking the way to reproduce or the environment to the submitter. jEdit core seems seized with creeping featurism while having over 200 bugs (and over 100 compiler warnings). http://sourceforge.net/tracker/?atid=100588&group_id=588 "Feature creep" in Wikipedia http://en.wikipedia.org/wiki/Feature_creep > Feature creep is the most common source of cost and schedule overruns. > It thus endangers and can even kill products and projects. See also "creeping featurism" in jargonfile. http://www.jargon.net/jargonfile/c/creepingfeaturism.html > When creeping featurism gets out of hand, it's like a cancer. Aren't you interested in those? -- k_satoda |
From: Shlomy R. <sre...@gm...> - 2008-09-30 17:50:28
|
In short: I am interested in making jEdit more stable and fixing bugs, but my time is limited and therefore I focus on things that are really useful for my own everyday work. I use jEdit at work and I try to add whatever features I am missing to make me more productive. When I run out of such features, or when I get a lot of time to work on jEdit, I will go ahead and do what you suggested here. Shlomy On Tue, Sep 30, 2008 at 7:40 PM, Kazutoshi Satoda <k_s...@f2...> wrote: > Shlomy Reinstein wrote: >> >> I'd like to add a capability to the hypersearch results dockable, to >> filter out results based on various criteria, such as path globs or > > (snip) >> >> Any recommendations? > > I want you to sweep existing bugs instead of implementing and testing > a new feature. > > Since sweeping bugs can be done by not only developers but also users, > I think this is good to say on jedit-users instead of jedit-devel, and > also this is a good time to say this because you looks seeking something > good to do for jEdit. > > I mean "sweeping bugs" as reproducing the bugs and apply the result to > the bug. The result can be changing the status appropriately, or just > adding a comment saying it was not reproducible in a environment. In > latter case, changing the status to Pending in the same time with asking > the way to reproduce or the environment to the submitter. > > jEdit core seems seized with creeping featurism while having over 200 > bugs (and over 100 compiler warnings). > http://sourceforge.net/tracker/?atid=100588&group_id=588 > > "Feature creep" in Wikipedia > http://en.wikipedia.org/wiki/Feature_creep >> >> Feature creep is the most common source of cost and schedule overruns. >> It thus endangers and can even kill products and projects. > > See also "creeping featurism" in jargonfile. > http://www.jargon.net/jargonfile/c/creepingfeaturism.html >> >> When creeping featurism gets out of hand, it's like a cancer. > > Aren't you interested in those? > -- > k_satoda > |
From: Kazutoshi S. <k_s...@f2...> - 2008-10-01 18:17:12
|
Shlomy Reinstein wrote: > When I run out of such features, or when I get a lot of time to work > on jEdit, I will go ahead and do what you suggested here. Thanks. I hope it comes in the near future. -- k_satoda |