Community
Participate
Working Groups
this would be a very handy search filter option.
we don't really know what files are 'open'. Editors can work on several files (e.g. the PDE editor) and even on non-workspace resources (not known to search)
very unfortunate .. i wouldn't expect the 'non-workspace' editors to be searched but the other case can't be that hard can it?
very unfortunate .. i wouldn't expect the 'non-workspace' editors to be searched but the other case can't be that hard can it? the reason this would be handy is because the 'selected files' search option doesn't work when i have focus set the the editor pane which is very annoying. i have to keep re-selecting the files in package explorer the searching but because i shift focus from editor the selected text from editor doesnt populate the search string.
I also don't like the 'selected resources' for that reason.
*** Bug 118618 has been marked as a duplicate of this bug. ***
*** Bug 50752 has been marked as a duplicate of this bug. ***
so still wontfix? it's obviously a desired enhancement .. maybe not very high priority, but still ...
It's a technical problem. Search doesn't know on what files editors work on. They can work on parts of files and worse on external resources not known to search. So adding the suggested feature will result in confusion: User has his PDE wizard open that shows a plugin.xml not in the workspace. On search with 'open in editors' is selected, no results would show up.
Could we add a "searchAdapter" to Editor's implementation, so that they could pass them the available "searchable" inputs. E.g. XYZ_Editor.getAdapter(ISearchableBlaBla.class) would return the object wich knows about all of internal "searchable" inputs. The AbstractTextEditor could pass than the only one existing input, the MultiPageEditor all available "text" inputs. I have not seen the source code of the search plugin yet, but I think this should be not very complicated. What do you think about such extension?
The problems are editors not working on resources or external files. You can argue that search then just would not find results there, but I think this would really look bad. The suggestion of an adapter mechanism is surely good, but it would also require all editors to implement it. Old editors wouldn't, and again search would be blamed for being incomplete.
*** Bug 301358 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > *** Bug 301358 has been marked as a duplicate of this bug. *** Hi Dani, I ended up adding this option to Pydev (requesting adapter to IFile), but in the process I had to copy and paste the FindReplaceDialog/Action (if you care to look how it appears, it's available when Ctrl+F is requested in pydev in the current nightly build -- update site: http://pydev.org/nightly -- and I think it's a pretty nice and streamlined way of doing that search in the open buffers and seeing the result in the search view). Anyways, I wanted to reuse the same code from Eclipse instead of having to copy and paste everything to add that custom functionality... should I open a bug to make that API available? (do you think it has a chance of being accepted?) Thanks, Fabio
Can you attach some screenshots or a short movie? We don't want to make the FindReplaceDialog API.
Also, how does your solution works e.g. in the PDE editor where you have multiple source files?
Created attachment 157789 [details] Snapshot for functionality
(In reply to comment #14) > Also, how does your solution works e.g. in the PDE editor where you have > multiple source files? I must say I still haven't tested with the PDE (I don't have the Eclipse SDK where I'm currently, so, I can't answer you right now, but it'd depend on how it answers to the GetAdapter(IFile.class) -- if there's something else that it should request to adapt to to get the multiple files it is viewing, it shouldn't be difficult to make any changes in the code to support it.
Your solution has the same problem as outlined here: there is no API/definition of an "open file". What if the file is opened by a view? What if the same file is opened by several editors? MPEs etc. For those reasons we won't add this feature.
Well, it may be that it's not available for 100% of all possible cases, but it's surely nice to have it working for the most common option (for me it's really 100% of my use cases) -- the only bad thing for me is not having the possibility of extending that dialog without making a copy of the code (for me that's the worse part as Pydev users will have it anyways -- but in a way that may become outdated if someday the Eclipse implementation evolves). For an integration that's a 100% proof, I think that it could ask for an adapter for IFile and if not available making another adapter for ISearchableBlaBla.class as Andrei suggested -- if it was done when suggested at 2005, by now I believe everyone would already have that :) I can provide a patch for that if you want... (and the implementation could give warnings saying which editors are not searchable in that case so that no one has surprises of things not being there -- and can ask for plugin implementors to add it as needed). As a second note, I've already used it for a couple of days and it's very handy on many situations (just not having to select the files before a search as in ctrl+h is a major win, as in many cases I want to search something in an already opened editor).
I'm sorry but we don't plan to add this. Instead of adding it to Find/Replace (where it does not belong), I think you could add it to Search (Ctrl+H) via little trick: contribute an 'Open Editors' or 'Open Files' working set via 'org.eclipse.ui.workingSets'. You can then search inside that working set. The nice part of this approach is that you can then also do a Java search in that space.
(In reply to comment #19) > I'm sorry but we don't plan to add this. Instead of adding it to Find/Replace > (where it does not belong), I think you could add it to Search (Ctrl+H) via > little trick: contribute an 'Open Editors' or 'Open Files' working set via > 'org.eclipse.ui.workingSets'. You can then search inside that working set. The > nice part of this approach is that you can then also do a Java search in that > space. Humm, I agree that it could be a workaround (although it'd have the same limitations if a proper support wasn't added), but by doing that, you'd loose all the usability of the feature (having to open ctrl+h, select working set, choosing that I want the open files working set, confirming and then starting the search is way too much -- compared to ctrl+f, alt+s). Also, for me, cognitively speaking, when I think about making a search in something I have currently open, ctrl+f seems closer than ctrl+h (which I see as something I must define a scope and make a selection on the tree or select a project or working set -- all which seems very far away from the open editors). Anyways, if that's your final word, I'm OK with it (although I really think it's a pity not having it by default in Eclipse, only through Pydev, as now that I'm using it I see how handy it is).
vote to re-open ...
(In reply to comment #21) > vote to re-open ... OK, but we won't have time to work on this. People who want this feature should provide high quality patch.
Vote for this. We definitely want to search the open files, they are important in our current context that's why we opened them before :) We know we just opened the files containing the function/code we are looking for.
