Community
Participate
Working Groups
It would be a very good feature to have highlighted search. To be able when searching to find all matches and highlight them, and also to mark them (like the warnings and the errors in the sidebar).
Search matches are shown as arrows in the ruler of an editor, in the overview bar (right bar of an editor) and in the text itself (M4 Build). The last two features have to be enabled in Preferences->Java->Editor->Problem->Indication. Please provide more information if you think this is not satisfactory.
Hi again, well I was refering to ordinary search using Ctrl-F It would be very nice if its posible to highlight all found matches with a diferent color. That way you can easyly see for example where are all usages of a variable or some substring. Its something like the search in Forte for Java or CTRL-F7 in "Idea". Best Regards, Dimitar Giormov.
Reopen and moving to JDT/Text
*** Bug 73972 has been marked as a duplicate of this bug. ***
Hi, I think this is fixed a long time ago. Using Ctrl-Shift-U combination. It works fine. best regards, Dimitar Giormov
Ctrl+Shift+U is not coupled to find (Ctrl+F) and only works in the Java editor for Java elements.
*** Bug 85040 has been marked as a duplicate of this bug. ***
Dani, bug 85040 was about plain text. Is there a reason why this should be a java-only functionality?
No. This bug has to go to Platform Text.
*** Bug 64297 has been marked as a duplicate of this bug. ***
I'm a little confused now. Should platform-text provide functionality just like Java "Show Occurrences in File Quick Menu" (Ctrl+Shift+U)? This performs a Search for the word which is currently under the cursor, and scope of the current file. Search results are displayed in an extra window, with sticky markers. It appears that the original submitter of this bug is happy with Ctrl+Shift+U as it works in JDT. Then there is the option of "Toggle Mark Occurrences" (Alt+Shift+O in JDT) which automatically marks all occurrences of the word in which the cursor currently is. This doesnt create sticky markers (they disappear as soon as the cursor is moved to a different word). It is a different, but equally helpful functionality since it doesnt require any user interaction in order to show the results. Finally, when I read the comments here right, there was a proposal to have something totally new integrated with Search/Replace (Ctrl+F). I currently don't understand the usage scenario how this would work (use the Search Results View or not?), and what the benefit of this new operation would be compared to the others. Could someone please clarify? Also, would this feature be a candidate for 3.2?
Find/Replace would allow to mark all occurrences. I agree that the 'Mark Occurrence' functionality which is currently in the Java editor could help as well but I think for a normal text editor it is not that common. >Also, would this feature be a candidate for 3.2? No.
*** Bug 123730 has been marked as a duplicate of this bug. ***
Hi I see 123730 is marked as a duplicate (sort of) so I thought I would give my two cents here: 1) I think there should be a "Find All" button in the ctrl+f "Find" dialog. The find all results should populate the Search view in the same way ctrl+shift+u does except with simple arrow icons instead of read/write icons. Reasoning: This would allow string literal and regex seaches to LIST all results in the current document which would be really useful. Useful not only for java code but many other kinds of documents long logs, xml, notes or whatever. Even MS Word can highlight all occurrences of a search. But I’m not saying that Eclipse should aspire to be Word. 2) I also think if there is a selection of length != 0 in the document and you do ctrl+shift+u it should bypass the popup (Identifier, Throwing Exception, Implementing Method) and find all occurrences of the selected character sequence in the same way that "Find All" would (except with find parameters: non-regex and case insensitive). In this case you wouldn't need to specify whether the occurrence is a read or a write in the occurrence icon. So you could just use a plain arrow. 3) It would be nice if ctrl+shift+u and mark occurrences matched java string literals too. Just to be clear, I mean the blue strings between quotes in java code. i.e. "param" in someMethod(“param”); Reasoning: This would be useful since some frameworks use Strings for some kind of mapping in which case a lot of literals are often used in code. But I think marking occurrences of string literals should not be a enabled by default since some people may not have a need for it, may find the highlighting annoying for string literals and if it is not used it is just an extra bit of code to slow down the editor performance. But for my needs I would be happy if just a single one of these features was implemented in the JDT. Does any of this make sense or sound like a good idea? :)
Created attachment 33046 [details] Here is a mockup of what I was thinking for the ctrl+f dialog in my first item
*** Bug 125720 has been marked as a duplicate of this bug. ***
Why is the dialog that narrow in width? It's text entries are barly capable to show usual class names; not to speak about non-trivial regular expressions.
Highlighting all matches is a common feature in vi/vim/gvim. Most of the users I know which moved from gvim to Eclipse, asked for such a feature. In fact, this is the reason I'm posting on this thread. Calvin I sustain your requirements 100%.
Created attachment 74001 [details] Initial effort (patches "org.eclipse.ui.workbench.texteditor") There are secondary things to handle on this one but here's an initial patch to have a basic "Highlight All" feature. It add annotations just like Ctrl+H annotations to Overview ruler. As secondary issues, I mean things like the decision to implement this from org.eclipse.ui.workbench.texteditor or from org.eclipse.jface.text; as Daniel stated in Comment #9. A few changes in Text about SourceViewer might be necessary. I also have another patch on org.eclipse.jface.text, as an effort to implement this from there. I'll also post it here when it's ready. This patch can be summarized like this: + Highlights and annotates with "Highlight All" button - Previous annotations are not removed when Ctrl+H search highlights the results. This is going to be solved in after a short period. - Doesn't highlight ConsoleView etc. works only in the editor. This is fixed in another patch and will be merged with this patch.
Hi Cagatay, I tried the patch but it does not seem to highlight all matches (it seems to miss the first occurrence). Here some detailed feedback: - The FindReplaceDialog must communicate only via find replace target. Setting a source viewer completely breaks the current abstractions. You need to add a IFindReplaceTargetExtension4 for this new feature. - The patch breaks layering by accessing stuff from a plug-in that it doesn't require (the search annotation type). The feature must also work for those that don't want the Search plug-in, e.g. an RCP application. - The highlighting stays too long. Maybe closing the dialog should also remove them. Another idea might be to use a push button with state: if pressed, the results are highlighted and if depressed they are cleared. - source code: make sure you add Javadoc everywhere, add the @since 3.4 tag on new members, add yourself to the copyright notes, update copyright date if needed, honor existing formatting, etc.
Created attachment 74158 [details] Correct approach (works but still needs work to be completely right) I've produced another patch in the light of Daniel's last comment. I hope the only remaining work is summarized as follows: TODO: - Create own annotation type - Add raw highlighing for targets that don't support annotations - Move status message NLS strings of "highligh all" to EditorMessages. BEHAVIOUR: * "Highlight All" toggle in Find/Replace dialog highlights/clears annotations. * If dialog is closed, annotations are cleared. PATCHES: org.eclipse.jface.text + IFindReplaceTargetExtension4 * TextViewer org.eclipse.ui.workbench.texteditor * FindReplaceDialog * FindReplaceTarget
Created attachment 74197 [details] Created its own annotationType * Create own annotation type - DONE I've also created an Update Site for those who want to try in a clean Eclipse install (since its still experimental): Update Site: http://user.ceng.metu.edu.tr/~e1394824/HighlightAllUpdateSite/site.xml You may not like the highlight color. :) I'm also attaching my work as a patch but it doesn't include marker icon (although I've added the icon, I couldn't include it in the patch) so you need to get it from the Update Site if you want to also see a marker on the left ruler.
Cagatay, I'm thrilled you're tackling this! I tried the update url you supplied, and it works well. Curiously, however, it also disables my WST HTML editor (I haven't tried the others) -- the editor disappears completely from my list of available editors. If I disable HighlightAll and restart, I once again can use the WST editor. Any idea what's going on there? I looked in my log and couldn't see anything of relevance.
I created the update site and the corresponding feature project in a hurry so I think that I may have made a mistake about versioning my build of jface.text and workbench.texteditor and this may be the explanation. The update site was just for test purposes. Don't worry I'm going to produce a final version without any problems soon.
Ok - I did see warnings about version mismatches on both of those, so that would fit.
Dennis the problem with WST HTML editor was because my patch was on jface.text and workbench.texteditor components from Eclipse HEAD. (version: 3.4.0.qualifier) WST requires [3.3.0,3.4.0) so WST doesn't accept my jface.text. I wanted to inform you about this small issue. I'm going to put the version that uses 3.3.0 components to the update site soon.
Awesome, a great opportunity to kill an old feature request!
Created attachment 74294 [details] Highlight All patch - org.eclipse.jface.text patch for 20070717-0800 Eclipse HEAD. Zip files include * org.eclipse.jface.text * org.eclipse.ui.workbench.texteditor projects. Externalized "highlight all" related strings (now in EditorMessages like other Find/Replace messages). - Tried adding raw highlighting (w/o annotations) TextViewer objects that are not an instance of SourceViewer. I could have added a method like public void setBackgroundColor(Color color, int start, int length, boolean controlRedraw) like TextViewer#setTextColor(), however I saw that setTextColor() method was logically wrong (removed other styling when foreground text color is set with this method). I wanted to implement this "raw highlighting" for "else" part in 5427th line in org.eclipse.jface.text.TextViewer class. However, it seems that, that "else" part has no corresponding scenario in the real world either. Here is that part ("else" part reflects what to do if a corresponding setBackgroundColor() method existed in API): if(isAnnotatible()){ AnnotationModel model = (AnnotationModel) ((ISourceViewer) TextViewer.this).getAnnotationModel(); Annotation findAnnotation = new Annotation("org.eclipse.jface.text.find",true,adapter.subSequence(widgetPos, widgetPos+length).toString()); //$NON-NLS-1$ Position position = new Position(widgetPos,length); model.addAnnotation(findAnnotation, position); } else { // TODO Add raw highlighing for targets that don't support annotations // Color highlight = new Color(getTextWidget().getDisplay(),255,255,0); // setBackgroundColor(highlight, widgetPos, length, false); } Other than this issue, I believe the patch is complete. An addition to implement for "Highlight All" is showing "soft matches" which are case-insensitive matches in a different color, whole word matches in a stronger color etc. like in Ctrl+H search highlighting. I'll work on it.
Created attachment 74295 [details] Highlight All patch - org.eclipse.ui.workbench.texteditor patch for 20070717-0800 * zip includes org.eclipse.ui.workbench.texteditor project
Regarding the version number issue: this is clearly a WST bug they should have something like: org.eclipse.ui.workbench.texteditor;bundle-version="[3.3.0,4.0.0)" etc. Please DO NOT create plug-ins that have the same version number as the one from the official release (e.g. 3.3.0). As you can see from the problems with your initial "patch" you can cause trouble for your clients. Even if you name it 3.3.0 it might then resolve but actually activate the wrong instance of that plug-in. I therefore marked your two attachments as obsolete. Please attach valid patches if you expect us to review them.
>Please attach valid patches if you expect us to review them. i.e. not ZIP(s) with the project(s) but one single patch file created bia Team > Create Patch...
(In reply to comment #26) I think you mean the org.eclipse.wst.common.ui plug-in it depends on, which because it's not API clean is intentionally using a narrower range of [3.2.0,3.4.0).
You mean it uses internal API from Text? In that case the version is OK. The "patch" should use something like 3.3.100.zzzMyPatch then to avoid problems described in comment 30.
Created attachment 74445 [details] Highlight All source patch (without necessary icon file "/icons/full/obj16/searchm_obj.gif" in org.eclipse.jface.text ) I'm sorry about wrong attachments Daniel. I hope this is the correct way, I'm also attaching necessary icon file. Since it's intended to be a source patch, versioning discussion doesn't matter right? It's a patch on current HEAD.
Created attachment 74447 [details] searchm_obj.gif (necessary icon file) should reside in <org.eclipse.jface.text plugin folder>/icons/full/obj16/searchm_obj.gif
>Since it's intended to be a source patch, versioning discussion doesn't matter >right? Right.
Created attachment 74449 [details] Highlight All source patch (updated for 20070724-0800 HEAD) updated the patch for today's HEAD
Created attachment 74801 [details] Highlight All source patch (updated for 20070724-0800 HEAD) I'm sorry I made a mistake in my last attachment. Here's the correct patch for 20070724-0800 HEAD.
JFace Text knows nothing about extension points (i.e. must not get a plugin.xml) and even if it would, you cannot reference an extension point that's in a much higher plug-in. Here some other comments in no particula order: - adding/removing is quite slow (looks sluggish) -> you have to do this batched in one call, see IAnnotationModelExtension.replaceAnnotations(*) for details. Also make sure not to call clear and then add/highlight. This also has to take place in a single replaceAnnotations(*) call - you need to attach the binary resouces separately. CVS patch format cannot deal with them :-( - if the Find text is altered we should remove the highlightings and reset the button - I think the dialog would look nicer if the new button is alligned to the right - use a more descriptive name for the annotation type, e.g. "Text Matches" as it is not sure that they are highlighted anymore once the user changes the preferences - don't show it in the vertical ruler per default. - never touch files you don't alter (e.g. the change to the copyright in the build.properties is not OK) - always add a mnemonic if you add a UI element that can get focus - referring to ISourceViewer inside TextViewer is a no go. A possible solution might be to extract the FindReplaceTarget into its own class (TextViewerFindReplaceTarget) and move it into org.eclipse.jface.internal.text. You can then subclass it to implement a SourceViewerFindReplaceTarget. - the new methods in IFindReplaceTargetExtension4 must mention that they are restricted to ISourceViewer and they should throw an IllegalStateException if this is violated - the dialog must disable the highlight button if the target is not an ISourceViewer
*** Bug 207401 has been marked as a duplicate of this bug. ***
Another use-case for highlighting all matches would be when using incremental find. The ability to see what possible matches are in the current file would be great. Like is works by default in Emacs (on Debian at least)
up :)
Can someone summarize the state of this bug/patch? I've read through the comments but I'm completely lost because I don't know which comment actually describes *requirements* and which *solutions*. *What* was proposed? *What* was implemented? Where is the patch? Is this request still relevant? Do we still need it? See also bug 501471 with a similar request. @Cagatay Calli: are you still there? If yes, do you mind to provide a Gerrit patch (see https://wiki.eclipse.org/Platform_UI/How_to_Contribute)?
Created attachment 264257 [details] screenshot of the search results screenshot highlighting the search results for the search term 'link' in an example file. The search term is highlighted with a background color.
(In reply to Andrey Loskutov from comment #43) > Can someone summarize the state of this bug/patch? I've read through the > comments but I'm completely lost because I don't know which comment actually > describes *requirements* and which *solutions*. *What* was proposed? *What* > was implemented? Where is the patch? Is this request still relevant? Do we > still need it? See also bug 501471 with a similar request. > > @Cagatay Calli: are you still there? If yes, do you mind to provide a Gerrit > patch (see https://wiki.eclipse.org/Platform_UI/How_to_Contribute)? Can't comment on the others, by my original request bug 73972), which was logged as dup. (comment 4) was suggesting that the "find" dialog would also highlight all the occurrences of the search term in the file, allowing for easy navigation to the searched term. Dirks comments in comment 2 indicates that arrows are added to the ruler which helps. This is sufficient for my purposes. bug 501471 has similar BEHAVIOUR, but the trigger is not the "find" operation, it is just the default text editor behavior. Notepad++ is a great example of this behaviour. bug 501471 is not a dup, but related. I've just realised that the file search (ctrl+h) provides the behavior that I was looking for except for all files - see Attachment 264257 [details] where the search term is highlighted in the file. I haven't tried any of the updates that were suggested. Hope that this helps.
