Community
Participate
Working Groups
I would suggest the search view to be a dual view in the same manner as the Call Hierarchy, i.e. search view should have a sub view listing line number and content of that line (the content could have some highlighting of the match)
That's what you get when stepping through the results: you see the match in the corresponding editor. If line numbers are enabled for that editor you will see them. You can also configure Search to only use one editor (instead of opening one per match). What exactly is it that you are missing from the current approach?
other editor I use list the content of lines, and I some times miss it in eclipse, it give me an easier overview, often I seach code for a special word and by seeing the rest of the line I am able to pick the right one the line numbers is not a key issue, the major reason I mentioned them is that they are present in the call tree views subview (I allways have search use only one editor)
Which "call tree" view are you talking about?
waiting for further user input
Sorry for the late response Try the following: in Eclipse-3.0M1 or later create new java project "HelloWorld" with the following class public class HelloWorld { void main(){ m(1); m(2); } void m(int i){ } } right click on "m" in "void m(int i)" definition and select "Open Call Hierachy" in the "Call Hierachy" view select the node "main() - HelloWorld (2 matches)" the buttom half of the "Call Hierachy" view will now show the calls that matches (unless you selcet "Horizontal View Orientation" or "Hierarchy View Only" in the view menu) i.e. | Location | Call --+----------+------ =>| line 15 | m(1) =>| line 16 | m(2) for Search I sugest the "Call" column should be replace with "Line Content" and the "Line Content" cell text should have the matched part underlined
I like the idea of actually seeing the matches (we do this, for example in the "occurrences in file" search). I doesn't necessarily have to be a second pane, though. I think there are two important notions here: 1) See the match context (i.e. the line text) 2) Have a match object visible that can be manipulated (i.e. deleted, selected, etc).
*** Bug 51231 has been marked as a duplicate of this bug. ***
updating summary.
*** Bug 57119 has been marked as a duplicate of this bug. ***
see also bug 46051
*** Bug 46051 has been marked as a duplicate of this bug. ***
*** Bug 72575 has been marked as a duplicate of this bug. ***
*** Bug 162318 has been marked as a duplicate of this bug. ***
Where can I see the matched text within the search pane? I only see it in the editor when I select the line. I would like to see it as well in the search pane. (In reply to comment #6) > I like the idea of actually seeing the matches (we do this, for example in the > "occurrences in file" search). I doesn't necessarily have to be a second pane, > though. I think there are two important notions here: > > 1) See the match context (i.e. the line text)
(In reply to comment #14) That's exactly the subject of this bug (and it has not been implemented so far). The only place where the search view currently shows contents rather than the enclosing declaration is in the Java Editor: select an identifier and choose Search > Occurrences in File > Identifier.
*** Bug 184364 has been marked as a duplicate of this bug. ***
Is this ever going to be "resolved" or better said the enhancement to be done? As far as I can see this would be about the same as jEdits hypersearch which is simply one of the most handy feature I've ever seen in an editor. (Have a lookt at it and play around with it :-) ). Actually this is the only reason that keeps me from using Eclipse instead of jEdit. But there are still other features of jEdit, that I miss in Eclipse (e.g. jEdits whitespace plugin, regular expressions in the search, rectangular selection, just to name a few) Best wishes, Chris.
(In reply to comment #17) Please vote for this feature if you consider it important.
>But there are still other features of jEdit, that I miss in Eclipse (e.g. >jEdits whitespace plugin, What does it do? Show whitespace in the editor? That's available in Eclipse out of the box (3.3 stream). > regular expressions in the search That's there for quite some time now.
Created attachment 73451 [details] Proposed patch We - three students - have implemented this feature as part of a course project. The search view now displays single matches as search results instead of files only, both in list and in tree view. For each match it shows the number and the text of the corresponding line. The matching text will be highlighted within the line. The color support is using a copy of OwnerDrawSupport from viewsupport of JDT UI. This should be replaced when owner draw support will be moved to the platform. It currently uses fixed colors; we should replace this by configurable colors, maybe appropriate settings already exist. It'll need some more testing and possibly some performance improvements but it seems to work quite fine in our limited tests. Thanks to Martin for some hints during the development.
Created attachment 73453 [details] Screenshot of tree view Everybody loves screenshots, so here is one.
Created attachment 73677 [details] Updated patch New patch updated to work with new color support in CVS and updated copyright headers. Displaying the line number for each match has been removed after feedback from Martin.
This is a feature that I always missed in Eclipse (got used to it because all other IDEs I'm using are displaying search results in this way). I was just about to open a new feature request when I found this one. Thanks for writing the patch! Just one question: What was the reason for removing the line numbers? Is there a possibility to make this feature configurable through the search view preferences?
Created attachment 74132 [details] Updated Patch The following updates have been made: - List view shows only resources, no line matches (old behavior) - Fixed names in copyrights When reviewing the result we found that the line numbers are not really necessary, but rather adds visual noise to the view. The shown string gives you a good context and you can easily navigate to the lines in the editor with double clicks. If there are more requests for line numbers we can add a preference.
patch released > 20070719
I'd really like to see a line-numbers preference switch :-) Another thing that would perhaps worth to think about is to add an option to show surrounding lines (perhaps these in another color), just the same as diff shows surroundin lines. I could imagine that a user could be interested in setting up how many surroundin lines are to be displayed and perhaps in what color. The actual search term is already highlighted as I can see from your screenshot, isn't it? Finally one more question,... when are we going to see this in an Eclipse release? The next big release or so?
This is released in the 3.4 stream and will be available in 3.4. Back porting to 3.3 is not planed, the changes are too big to guarantee that we don't introduce majors bugs or performance problems to 3.3. We will use the time until 3.4 is released to test these issues and get more user feedback. Interested users are recommended to use our 3.4 milestones (not yet scheduled, but expected to start in August).
(In reply to comment #24) > Created an attachment (id=74132) [details] > Updated Patch > > The following updates have been made: > - List view shows only resources, no line matches (old behavior) > - Fixed names in copyrights > > When reviewing the result we found that the line numbers are not really > necessary, but rather adds visual noise to the view. The shown string gives you > a good context and you can easily navigate to the lines in the editor with > double clicks. > If there are more requests for line numbers we can add a preference. > I would very much like to see the line numbers. Having them there tells you at once if what you're looking at in the edit pane is the same thing as what you're looking at in the search result pane.
FYI: this completely broke the file only search (see bug 199236).
(In reply to comment #24) > Created an attachment (id=74132) [details] > Updated Patch > > The following updates have been made: > - List view shows only resources, no line matches (old behavior) > - Fixed names in copyrights > > When reviewing the result we found that the line numbers are not really > necessary, but rather adds visual noise to the view. The shown string gives you > a good context and you can easily navigate to the lines in the editor with > double clicks. > If there are more requests for line numbers we can add a preference. > Why did you kill text snippets in list view? List view is the most convenient representation of search results when the number of matches is small. It would be very useful to have an option to show line matches in list view. In many cases this would give user a single-glance high level view, potentially saving a lot of clicks and keystrokes. The whole discussion about the best form of search output should be resolved by adding preferences, so that everybody could configure search their favorite way.
In the list view the line length becomes very long as you have to append the resource name and project name. I found it less useful than before.
(In reply to comment #31) > In the list view the line length becomes very long as you have to append the > resource name and project name. I found it less useful than before. > People use monitors of different sizes. To avoid imposing a personal preference of some on everybody, presence or absence of text line in the list view should be configurable. The same applies to the line number column.
(In reply to comment #32) > (In reply to comment #31) > > In the list view the line length becomes very long as you have to append the > > resource name and project name. I found it less useful than before. > > Perhaps an output like this would be good, saving some vertical space: 'Hello' - 2 matches in workspace (*.html,,*.java,*.txt) bar_project\src\bar_package\barclas.java\ 5: System.out.println("Hello, Bar!"); 17: System.out.println("Hello yes!"); foo_project\src\foo_package\fooClass.java\ 5: System.out.println("Hell, Foo!");
I like this output format. It's very compact. (In reply to comment #33) > Perhaps an output like this would be good, saving some vertical space: > > 'Hello' - 2 matches in workspace (*.html,,*.java,*.txt) > bar_project\src\bar_package\barclas.java\ > 5: System.out.println("Hello, Bar!"); > 17: System.out.println("Hello yes!"); > foo_project\src\foo_package\fooClass.java\ > 5: System.out.println("Hell, Foo!"); >
(In reply to comment #33) > (In reply to comment #32) > > (In reply to comment #31) > > > In the list view the line length becomes very long as you have to append the > > > resource name and project name. I found it less useful than before. > > > > Perhaps an output like this would be good, saving some vertical space: > > 'Hello' - 2 matches in workspace (*.html,,*.java,*.txt) > bar_project\src\bar_package\barclas.java\ > 5: System.out.println("Hello, Bar!"); > 17: System.out.println("Hello yes!"); > foo_project\src\foo_package\fooClass.java\ > 5: System.out.println("Hell, Foo!"); > Many thanks to all who contributed to this code. I use it daily and like it a lot. I'm going to take back what I said about the format I suggested here. I like the existing format better. Although it involves more scrolling, it's a lot easier to read and more consistent with how the rest of eclipse looks. The more I use this feature, the stronger I feel about two things: 1. I really miss the line number information. 2. I would prefer that a line with the match results only be shown once, regardless of how many matches the line contains. What I mean is let's say for example the search word was Hello. I would prefer to see 5: System.out.println("Hello, Hello, Bar!"); rather than 5: System.out.println("Hello, Hello, Bar!"); 6: System.out.println("Hello, Hello, Bar!"); (Hello highlighted in all cases)
> 1. I really miss the line number information. I filed bug 207274 for this. > 2. I would prefer that a line with the match results only be shown once, > regardless of how many matches the line contains. See bug 199044. However, I think this is less of an issue when line numbers are shown.
note that I fixed bug 207274 and bug 199044: Line numbers are shown again. Same line is used for multiple matches on a line.
You really should make this more configurable. Each user should be able to choose if he wants to see line numbers (I think that should be probably the default) and if he wants to see multiple results per line (I think that should be disabled per default).
Let's first try it. It would be great if we can avoid options. It doesn't only make the UI more complicated, but is also a lot of work to maintain.
I just switched from Eclipse 3.6 to 3.7 and noticed that the search view doesn't show line matches any more. Is there a setting somewhere to toggle this feature? Or any other ideas of how to get them back?
(In reply to comment #40) > I just switched from Eclipse 3.6 to 3.7 and noticed that the search view > doesn't show line matches any more. Is there a setting somewhere to toggle this > feature? Or any other ideas of how to get them back? Search view menu > Show as Tree.
(In reply to comment #41) > (In reply to comment #40) > > I just switched from Eclipse 3.6 to 3.7 and noticed that the search view > > doesn't show line matches any more. Is there a setting somewhere to toggle this > > feature? Or any other ideas of how to get them back? > > Search view menu > Show as Tree. Thanks for the suggestion, but it's already set to Show as Tree. :(
Are you sure you're using normal File search? Also verify that General > Appearance > Use mixed fonts and colors for labels is selected.
(In reply to comment #43) > Are you sure you're using normal File search? Also verify that General > > Appearance > Use mixed fonts and colors for labels is selected. Yes, use mixed fonts is checked. I have the normal File Search and Aptana File Search available (just like I did in 3.6) and both produce the same results. Here's a screenshot: http://i56.tinypic.com/n1850g.png
Does it happen on all files? Maybe a label decorator destroys the match highlighting (try by disabling all of them).
(In reply to comment #45) > Does it happen on all files? Maybe a label decorator destroys the match > highlighting (try by disabling all of them). Yes, it happens on all of my searches so far in 3.7. I disabled all label decoratorss and it didn't fix it.
I rebuilt my Eclipse install from scratch again and this time (for whatever reason) the search view is working correctly. I thought perhaps it was one of my plugins that was interfering somehow so I tried to rebuilt my install just as I'd done a few days ago and tested the search view as I went but couldn't reproduce the problem. Anyway, it works now!
(In reply to comment #47) > Anyway, it works now! Glad to hear that.
This feature would be great for Java Search as well. After a reference search (Shift-Ctrl-G), by seeing all lines involving a variable, one could very quickly grasp the overall usage. Is this bug report only related to File Search?
(In reply to comment #49) > This feature would be great for Java Search as well. After a reference search > (Shift-Ctrl-G), by seeing all lines involving a variable, one could very > quickly grasp the overall usage. Is this bug report only related to File > Search? Please file a separate bug against JDT.
(In reply to Sergey Prigogin from comment #50) > (In reply to comment #49) > > This feature would be great for Java Search as well. After a reference search > > (Shift-Ctrl-G), by seeing all lines involving a variable, one could very > > quickly grasp the overall usage. Is this bug report only related to File > > Search? > > Please file a separate bug against JDT. Anyone done this? Would be REALLY nice to have the matching line in the search result view for ALL searches.
Done, see bug 47136
Sorry, paste mismatch, see bug 443095
(In reply to Martin from comment #53) > Sorry, paste mismatch, see bug 443095 Thanx, Martin -> voted! :-)
