The new find-bar
Hi,
I like the idea of the find bar that looks like the one in Firefox. It's a nice feature.
One thing I don't like about it is how it totally ignores the current look and feel. It has always that ugly gray gradient in the background. Please at least use the window background color of the look and feel as the base of the gradient if it has to be a gradient at all. And the text field should be a text field and not some gray area with a line border.
Cheers,
Robert
P.S.: I'm on a Windows XP machine here. So I'm used to some ugliness, but the Mac users will probably have a nervous breakdown when they see it ;)
Please sign in to leave a comment.
Well, the functionality is wicked cool enough that the fact that it is visually jarring on the mac doesn't scare me too much. Plenty of time between now and release to tweak the visuals.
--Dave Griffith
It is very sweet. Very nice.
If you quick search for something, is there a way to re-quick- search for the same term?
http://www.intellij.net/forums/thread.jspa?threadID=269342&tstart=0
I hate to be a party pooper, but the new find bar is a loss of functionality. Namely, regular expression searching.
However, I do like the way it looks and the way it highlights all occurrences.
Message was edited by:
Gordon Tyler
Hello Gordon,
You're now supposed to use "Find in Path" for that, which should have a new
scope option for searching in the current file (don't remember if it's already
there in the current build, but if it's not, it'll appear when Max comes
back from vacation :) ).
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
I would never have thought to do that. Rather counter-intuitive if you ask me.
</grumpyoldman>
Just add a regular expression checkbox like you did for "Case sensitive" and "Match whole words only". Heck, I never use "Match whole words only", what use is it?
The current selection seems to get cleared when the search starts: is
there any way to search within the currently selected text?
R
I never had to use Find in Path before.
Current File is an option under the Custom radio button. Unfortunately, it is not a running default. Futhermore, it is implicitly and unconditionally a "Find All" style search, with no incremental option. Nor does Find in Path change the search pattern associated with F3.
All in all, I think more fragmentation of search functionality is not a good thing. If anything, it should be unified more.
The fact that some finding now avoids a modal dialog is good, but as other have mentioned many times, there are too many modal dialogs in IDEA.
Also, the minimum width of the Find in Path dialog is too wide. Its options section wastes a lot of space, too. Likewise the lack of vertical overlap between "Skip results with tab with one usage" and "Open in new tab" check-boxes.
Randall Schulz
I like the new inline find. Safari 3 beta has also adopted the Firefox-style find bar.
Here are the issues I found so far:
A. I think the keybindings should work the same as incremental search. For example,
A-1. While in incremental search mode, it would respond to user's Up and Down
keybindings. I use Emacs-style keybindings, so I have CTRL+Up for Up and
CTRL+N for Down.
A-2 While in incremental search mode, you could break out of the mode by moving
the cursor right or left, e.g. LEFT_ARROW, RIGHT_ARROW, CTRL+LEFT_ARROW,
CTRL+ RIGHT_ARROW. Also Expand Selection (CTRLW), Cut (CTRLX), and other
editing commands also cancel the search mode. Firefox find bar doesn't
support this, but in a browser you aren't looking for text in order to edit
it. For IDEA, you need to support this behavior because often you are
searching for something in order to edit/cut/copy/etc. the text or nearby
text.
A-3 In incremental search mode, you can press CTRLUP_ARROW or CTRLDOWN_ARROW
to scroll the file in the editor while staying in search mode.
B. Behavior
B-1. If I start a search, and the "text" I am looking for is above the current
line, IDEA is wrapping around and jumping to the top automatically. If
there is one match of "text" below me, it will first goto that match, and
then if I press F3 again, it says "text" not found, press F3 to search
from the top. I think it should prompt me also in the first case if there
aren't any more matches w/o wrapping to the top.
C. Colors
Before, the Color setting General->Search Result was being used to color
incremental search matches and Highlight Usages in File (CTRLALTF7), and
General->Search Result (write access) was used by Highlight Usages in File to
highlight usages where the variable is written to.
Now, it is using Text Search Result{Background yellow, error stripe green} and
Selection Background{background faded yellow}
C-1. Can't you just use the existing Search Result and Search Result (write access)
If not, I recommend the error stripe should be the same color as the search highlight
color, or at least the same hue. It is confusing if one is yellow and one is green imo.
C-2. Will the new find still offer the "write access" coloring?
Hello Gordon,
Well, its main use is that it dramatically speeds up whole-project searches
(because searches with "match whole words" use an index rather than directly
scanning all files). It's probably much less useful for single-file searches,
indeed.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
I too like this new find functionality
Francesco
It would be nice to give the option to display the find bar at the bottom of the editor pane instead of the top.
Firefox has the find bar at the bottom.
Safari 3 beta has the find bar at the top.
I personally prefer the find bar at the bottom because (1) I use firefox so I'm use to it and (2) after you get used to it, you dont' need to look at the find bar, but instead you are focused on the matches. So, I would like the find bar itself to be in the least prominent location -- which would be at the bottom for me.
+1
--Dave Griffith
But as I mentioned (http://www.intellij.net/forums/thread.jspa?threadID=269342&tstart=0), using the editor pane when there is unused space in the button bar is wasteful.
Randall Schulz
Has been said before, but these two should really be made part of the new UI:
- regular expression searches (have to invoke find in path and then
finding an option to only find in file is an ui blooper).
It's just a checkbox to add.
- search history: I often use it to repeat one of the previous searches
Again, shouldn't it be easy to integrate.
Other than that: Wicket cool, esp. the incremental highlighting.
Hello Stephen,
JIRA issues please?
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
See IDEA-14548 and IDEA-14549
Thanks!
I have been waiting for something like this since I first started using IDEA. I even asked for something like it a long time ago(pre JIRA); but this implementation is better.
And, I like it.
At the risk of taking something simple and possibly overloading it, there are two buttons I would love to have, between the text entry, and the find next/prev buttons.
1. A button to find using selected text. That is you select the text and then either click the button(or use a keyboard combo) to have it automatically use the selected text for the find.
2. Clear. It just empties out your selection and resets; gutter marks are gone, along with highlighting.
http://www.jetbrains.net/jira/browse/IDEA-14548
http://www.jetbrains.net/jira/browse/IDEA-14549
1. Select text. Press Ctrl-F (or whatever your Find keybinding is).
2. Press Escape.
Step 1 works. Thanks. Step 2 closes it, so I skip that.
Though, a button would also be nice, when I am using the mouse to do the selection(which I do a lot).
They weren't steps, they were replies to your two requests.
Anyway, selecting text with the mouse and then clicking the normal Find button in the toolbar does the same thing.
Should the Find Word at Cursor command change the value of the find field?
If you do a Ctrl-F3 to do a Find Word at Cursor, and then when you do a find next, you are doing find next of the result of the Find Word at Cursor and not the value in the find field(same for the highlighting). That might be confusing.
Gotcha...my mistake on that.
Except on 2, I don't want the find bar to go away...I like it there, where I don't have to go hunting for it(or, possibly better, on the toolbar, since there is room); sort of use to that using UltraEdit.
But, the first 1 does work, whether the find bar is open or not. So that is good. Thanks again.
So if I understand correctly, you want the Find bar to be always visible so you can just click in the field and start typing, with a button to clear the highlights etc.?
Yes.
Never liked having a find popup box to deal with(unless I was going to do something complex or out of the ordinary).
I am sure this will elicit a few '"well duh"s from the audience, but I just noticed how the new find UI stays attached to a tab.
That is, once I open it for a tab, it remembers the find I did in that tab, even when I go to another tab and do a different find. Another reason just to leave the new UI open all the time. :)
I am liking this Find UI more and more.
Agreed. I personally love that you can have a separate find box on each editor pane when you split your panes horizontally or vertically (or both). Very cool :)
Hello Dmitry,
"Current file" is an available scope in 7241.
How about a predefined scope for "all open tabs"? This could be a very useful search scope, since a user will typically have "related" files (or files relevant to the task at hand) open in the multiple editor tabs. But such a scope does not appear to be one that a user could custom define.
And another one for "all visible panes" when using split panes would be great as well.
(JIRA for you: http://www.jetbrains.net/jira/browse/IDEA-14572)
Do you think Max will be rested up enough from vacation to tackle those? :)