Community
Participate
Working Groups
Currently searching in the editor is only possible if you select a word before. This is quite inconvenient and a blocker for those like me who worked with a different approach for many years. I suggest to include an option to preset the search dialog with the word that currently contains the cursor if nothing is selected. This way one can save to select one first. Mike -- www.delphi-gems.com
Just to clarify: do you mean when opening the Find/Replace dialog (Ctrl+F) or when using Find Next (Ctrl+K)? I agree and support the Ctrl+K case but not on the Find/Replace dialog case: there it is better to have the last search string if there's no selection. I adapted the summary to reflect the Find Next (Ctrl+K) case.
I'm not sure what the advantage would be for Ctrl+K (find next) search. This case does not open a new dialog, so the only way would be to search the word under the cursor and jump to the next location. However the term "search next" implies that we are searching *again* for something. So there is a semantic conflict. Ok, you could say: then let us use the word under the cursor only if there was no search yet, but this is almost completely useless. This would work once and then never again until you close Eclipse. No, what I'm after is the Ctr+F dialog. I don't know what sense it makes to fill the search box with the last search term. I mean, there is "find next" for that case. "Find first" means "search for a new term" and I want to enter this new term. If I want to search for the previous search term then I would use "find next". If there is nothing selected then it would make perfect sense to search for the word at the cursor location.
If you think a change would offend other users then include an option switch, which decides about this behavior. The actual implementation should be absolutely trivial.
>However the term "search next" implies that we are searching *again* for >something. No ;-) It can also mean find the next one which is the same as the currently selected in the editor. That's what it does. You can select a word and press Ctrl+K to jump to the next instance.
I see, you are tough :-) I have to agree that this is a valid case. Different users have different ways to work. However this does not give me my way to work (and for others who are used to that behavior too). As I already wrote one could switch the behavior by adding an option to the settings for the editor. It is just the text, which is initially used in the search dialog, which must be exchanged. What I also wonder about, though, is why search scope "all" does not search all, but starts from the current line. Thank you for taking the time to read my feature wish.
>What I also wonder about, though, is why search scope "all" does not search >all, but starts from the current line. The scope doesn't tell where it starts it just tells you whether its the whole document or the selection. When wrapping is enabled then it will search from top once you reached the end. Most users expect and therefore most tools start searching Forward (or Backward) from the current location and not from the top.
Right, in other tools (like Borland Delphi) there is another switch to tell to search from current cursor location or from the start of the document (which I almost always prefer). This has nothing to do with the scope. I can see that it makes a lot of sense as the search function is now and I don't say it should be replaced by something else. All I request is that I can optionally switch to another behavior, which served with well with other tools for more than 15 years of software development. I can imagine you are quite busy (that's with me too) but the required changes should be doable within 30 minutes plus another 15 minutes for QA. This is really not a big deal. If I wouldn't be so new to Java and Eclipse I'd provide you a copy'n paste solution. Thank you for listening anyway. Mike
I have always wanted Find Next/Previous to search for the word under the cursor if there is no selection. I don't care about the Find dialog because I am always using the shortcuts (Ctrl+K and Ctrl+Shift+K). So I created a small plug-in which adds two new commands: "Search Next" and "Search Previous" which search for the work under the cursor if there is no selection; otherwise they simply delegate to the corresponding Find command. I have bound my new commands to Ctrl+K and Ctrl+Shift+K and this way I get the behavior I want. You can download the plug-in here: http://eclipselabs.org/p/eclipse-tweaks/ If the Text team think this is a useful feature I could prepare a patch which provides these commands out-of-the-box.
> If the Text team think this is a useful feature I could prepare a patch which > provides these commands out-of-the-box. Adding additional commands is overkill. A solution would be to enhance the current actions. A good quality patch for that would be welcome.
I would consider it a severe regression if Ctrl+K wouldn't leave the Find string intact. I often use Ctrl+K to jump through occurrences of a name (or a qualified name etc.), and after I did something in the vicinity of a match, I continue with Ctrl+K. If that fills something into the Find buffer, that's a no-go. I'm not sure if it's really a good idea to add a compound action for "select word" and "find next". If I need that in a Java editor, I just use Alt+Shift+Up to select the word and then press Ctrl+K (bug 23080 is for pushing the "select word" action up into all text-based editors). If I had to decide between 2 new commands and an additional checkbox in the preferences, I'd prefer the commands.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
