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.
I've been using 7241 for about 30 hours now. (I was working all weekend. We're in the last few days before code complete milestone.)
The main point I was to reiterate is that if this inline find is going to replace the incremental search, then the keyboard behavior needs to be the same.
It has been pretty frustrating that I can't break out of the new incremental find by pressing LEFT_ARROW, RIGHT_ARROW, etc. I know I can hit ESCAPE to exit the find mode, but that is one extra keystroke I have to do that I didn't do before.
What I suggest is that the textfield in the inline find panel should not capture any keytrokes by default. All keystrokes need to handled by a special handler similar to the old incremental search. The inline find textfield should act like a display label unless someone clicks on it; Then it could become editable like a regular textfield.
Please see http://www.jetbrains.net/jira/browse/IDEA-14717
The elimination of the old Find dialog in favor of the new search bar has degraded usability seriously.
One or more of the following should be implemented to rememdy the degradation:
The new find bar should have a regular expression check-box.
All settings in the "Find in Path" dialog should be made running defaults (remembered from one use to the next).
When "Curent File" is chose, the File Name Filter should be ignored, even if enabled.
Layout and placement of controls in "Find in Path" and "Replace Text" should be optimized to avoid waste and minimize their size.
The old Find dialog should be available as an option.
Randall Schulz
+1 I like the new Find bar concept, but I miss the history and regular expressions.
It just me (and another guy at the office) or is the backspace key (delete key) not working in the find bar?
Also, some clarification on the difference between find and find in path would be helpful at this point.
Thanks,
Backspace in the find bar works here.
Hi,
The find bar in 7269 is a clear improvement. However, three minor issues have appeared:
1) ALT+R does not toggle Regex mode (the mouse must be used)
2) When in Regex mode and patter is has a RE syntax error, the diagnostic ("Incorrect regular expression," I think) overwrites other contents in the find bar.
3) Sometimes when Regex is checked, the pattern is interpreted as a simple string (non-RE)
Randall Schulz
Message was edited by:
Randall Schulz
Find bar looks nicer now, but I saw no improvement on supporting the keyboard behavior of incremental search.
What you have now is a nice replacement for Search->Find.. dialog, but unless something changes dramatically between now and the release, this inline find bar is NOT a drop-in replacement for the incremental search, and you need to revert incremental find to the old implementation, leaving this new inline find to only replace Search->Find. Even if you will somehow resolve the issue, in the meantime, I would really really appreciate you to revert the incremental find back to the old one since I am doing real work with the EAP (silly me! lol) and it's a pain in the #$%.
I personally solely used incremental search and not Search->Find, so I am very sensitive to how the keyboard behavior, esp. the how easy it is to breakout of the mode (as detailed in my post above.)
The other point I wanted to reiterate is to remember that IDEA is an editor first and foremost and not a browser, so you need to be careful in emulating the inline find of Firefox and Safari too closely. The browsers don't need to accommodate quick inline editing, well.. because people aren't editing web pages!
On 2007-09-09 10:39:18 +0400, Alex <no_reply@jetbrains.com> said:
Well, we'll enable as many actions as possible there but unlikely will
change search field to uneditable control like old incremental search
handler was. Thus, actions like LEFT_ARROW, RIGHT_ARROW, SELECT_WORD
will operate on search field, not the editor being searched. Also, I do
not think having a separate mode for the same UI is a good idea, the
difference between old incremental search and new incremental search is
too subtle to a newcomer to understand. However, old implementation is
still there and you can just assign a shortcut to it (Other|Incremental
Search).
Nope. At least in 7269, I have CTRL+S mapped to Other->Incremental Search. But
when I press CTRL+S, it shows me the inline find bar. Do you want me to file
a Jira?
Ok, I think I understand issue. Now that the modal Find dialog is inline, it is
also incremental, i.e. jumping to the first match immediately, just like the old
incremental search.
But the incremental aspect was only one part of the difference of Incremental
Search and the Search->Find dialog. The other huge part as I mentioned was the
keyboard behaviour.
And where I disagree is I don't think the remaining difference is 'subtle'.
Before I could breakout of the search with almost any key, similar to how you
can accept the code completion and keep on typing, but now I have to hit ESCAPE
key before I can continue typing. I hate having to hit the ESCAPE key! I
originally came to IDEA from Emacs which had incremental search CTRL+S (plus
CTRL+R for reverse search which IDEA never supported). As you know Emacs keymap
is focused on making all the often used commands accessible without moving your
hands, e.g. CTRLG to cancel instead of ESCAPE, CTRLE instead of End key for
end of line, etc. I still have my keymap setup like this as much as IDEA will
allow me too, and if you do this, you notice what a pain it is to reach up and
hit the ESCAPE key.. Anyway, I digress...
I had thought Jetbrains could add their own tweak to the Firefox/Safari style
find bars, so that we could have the best of both worlds, i.e. the incremental
searching and keyboard behavior of the incremental search, plus having access
to the options of the modal find dialog, but it seems no effort has gone into
that.
You could simply make the TextField uneditable unless clicked on, and have all
keys handled same as the old incremental search. I still don't see the
downside of doing it like that. When I use incremental search I am usually
just typing a string to match. The only keybindings I would want the TextField
to listen to by default is DELETE, CTRLDELETE, BACKSPACE, CTRL BACKSPACE,
Paste(CTRLV). Anything else like Select Word (CTRLW), LEFT_ARROW,
RIGHT_ARROW, etc. etc. should immediately breakout of the search and be applied
to the editor. Seems straightforward to me.
In fact, the current behavior is closer to what I am suggesting if you search,
then click on editor, then Search->Find Next again. For example, say I am
searching for a pattern, and for each match, I need to make an edit in the
Editor.
1. Search->Find
2. Start typing some text
3. Press F3 Search->Find Next
4. ESCAPE
5. Now I navigate/edit text on the line where pattern matched.
6. Press F3 Search->Find Next
7. Now I can immediately navigate/edit text without hitting ESCAPE.
This is not good that the first time you had to hit ESCAPE, but each time
after that you did not. Can't you make it so you don't have to hit ESCAPE even
that first time? It seems like your 95% there already. Otherwise, the old
Incremental Search is still more productive because it avoids the initial
TextField key trap.
Sorry to make a big stink about this, but this feature is a very basic editing
feature and I use it alot. I think you guys need to be more careful making
changes to basic features like this. I wouldn't have been as upset if you hadn'
t remapped my Other->Incremental Search to this new find bar. But I would
really love to see a unified inline Search->Find which stays true to the old
Incremental Search keyboard behavior since it is more productive and therefore
more pleasurable, so that's why I thought I'd try one more time by writing this
lengthy note.
As a side note, It will be interesting to see if Eclipse tries to copy IDEA's
inline find, because they have the same Edit->Find/Repleace and Edit->
Incremental Find features, and whether they will do it the same way.
Yes please.
It doesn't seem consistent, you know. Some editing functions go to the
text field and other to main editor. If it looks like a text field it
must accept all textfield editing actions. Like LEFT, DEL, DEL must
delete last two characters in a field.
I did :)
Well, I think I can live with the Find Bar replacing the Incremental Search functionality, but it
should not share its settings with those of the "regular" action:
http://www.jetbrains.net/jira/browse/IDEA-14542
To be honest, to me the Find Bar feels much more like an incremental search than a replacement for
the old find dialog. It's simply about the expectation that when invoking a find command usually a
dialog has to pop up ;)
Sascha
Done.
Other->Incremental Search is bound to the new inline find bar Search->Find
http://www.jetbrains.net/jira/browse/IDEA-14850
>
>
>
Anyone used to using the old Incremental Search wouldn't
be confused because that's how it worked before. The only
confusion might be with users that mainly used Search->Find,
but since the textfield would be disabled (click to edit),
I don't think it's that confusing... and once they understand
they will be more productive because you don't have to hit
the ESCAPE button to break out of the find mode, similar to
how you can press any key to finish a completion. Probably 99.9%
of the time no one will ever have to click the textfield to edit
it.
And I already pointed out the current implementation is inconsistent
because you have to hit ESCAPE after the initial Search->Find,
but successive Search->Find Nexts, you can immediately break out
by navigating/typing in the editor.
Search->Find
Search->Find Next
Search->Find Next
Search->Find Next
ESCAPE <==== Here I have to hit ESCAPE to break out.
Search->Find Next
Search->Find Next
<===========Here I didn't have to hit ESCAPE
I can think of other much more confusing changes (jamming the tabs
into the tool window titlebar to save space), that are done for the
sake of development pleasure.
I'm a UI developer, so I'm all for standard and intuitive design, and it's
ironic I'm arguing for some non-standard textfield behavior since I'm the one
who filed IDEADEV-20413 "IDEA TextFields should support Move Caret to Line
Start, Move Caret to Line End, and Select All keybindings." which has been
implemented in Selena, which BTW is great productivity improvement.
The key difference is that the inline find bar is a non-standard UI to begin
with; Jetbrains has chosen to implement the search pattern box as a TextField;
That is where the mental logjam appears to be.
In fact, you can make it a JLabel with a little tooltip that says "Click to
edit". There, now it's no longer inconcistent. I feel all better, already.. lol
Anyway, I don't think I can argue my point any better without going in circles
now, so please consider one last time, and in the meantime please restore the
old Other->Incremental Search so my keybinding CTRL+S works again, and I'll be
on my way.
Hi all,
I have a small frustration with the new search UI. When I search something, and I find the first result, pressing ]]> doesn't give me the next result, but the focus is in the IDE, cause me to delete the word currently in focus.
Now you'd might say: why press enter? Well, when I use Firefox, Opera, Word, Textpad, whatever other search in a program, ENTER brings me to the next result found. Is it possible to change the search bar in IntelliJ to match this behaviour? Now I have to search in the menu what the incremental search is (it's not inituitive).
Having focus in the search bar until pressing Escape is IMO a far better solution than having the focus in the text editor, and incidentally removing text (which happened to me a few times now).
You can sequence back and forth through the hits with the up and down arrow keys. Isn't that better?
I'm with those who think that a browser UI is not necessarily the proper model for this aspect of an IDE's UI.
Randall Schulz
Funny you say that, because I completly agree. Actually, I tried to search a couple of times, but I missed the search input, because it's somewhere up in my screen, instead of in the middle, where I'd expect it to be.
For me, it's quite annoying to put my cursor somewhere at the bottom at te screen, type what I'm looking for, but the thing I'm looking for is usually located near my cursus, so I have to look up/down/up/down to know what I was looking for ;). Maybe it has something to do with the 1920x1200 + 17" laptop + tiny font layout, but looking this far is somewhat annoying.
I thought about dragging the search bar at the bottom of the screen, but this
a) doesn't work
b) would probably not be very useful when I place the cursor at the top of the screen.
Actually, in contrary what I said before, I think I don't like the new search UI, and would opt to revert it to the old search UI, or improve the current one so that everybody is happy (but I don't think there where any complaints about the old one, so what was the motivation for the new search UI in first place?)
Comparison to Netbeans 6.0b1 find-bar
See attached screenshot of the Netbeans 6.0b1 find bar, accessible by Edit->Find (CTRL+F).
Overall, the Netbeans inline find bar works almost the same as IDEA find bar. Below are some differences
saw.
(1) Location
Netbeans find bar is at the bottom of the editor pane.
IDEA's find bar is at the top.
Comments: This is matter of personal preference, although I think if you used to the old
Incremental Search, your eye is not on the find bar but rather on the match in the editor.
The only time I glance at the find bar itself is if I'm getting no matches so I need to check
to see if I had a typo. So, I would rather have it at the bottom where it is less distracting.
Verdict: Personal Preference, but IMO +1 Netbeans
(2) Repeating Last Search
Netbeans Pressing CTRL+F twice immediately searches for the last search phrase.
IDEA CTRL+F pops up a list of recent searches. You have to ENTER to initiate the search
of the last item.
Verdict: 1 Netbeans. Many incremental search features in other editors do like Netbeans and repeat last search when the key (CTRLF or CTRLS usually) is pressed twice. Since searching for last term is most common, IDEA should support this convention. Also, you'll see below that restarting the search with CTRLF CTRL+F would be desirable because when the search box as focus, you can use Editor->Down and Editor->Up to navigate.
*(3) Find Next / Find Previous *
In Netbeans you have to do Find Next or Find Previous to jump to the next/previous match.
In IDEA, you also can hit Find Next or Find Previous, but in addition when the search box has
the focus, you can use Editor->Down for Find Next and Editor->Up for Find Previous. For Emacs
people that have added CTRLN to Editor->Down and CTRLP for Editor->Up, this works.
So in IDEA, I can almost avoid moving my wrist while searching, except I have to hit ESCAPE
to break out of the find mode.
Also, once you breakout, if you want to goto the next match, you have to use Find Next or
Find Previous, unless you put the focus back in the search box by clicking on it
or by hitting CTRLF CTRLF ENTER. The Editor->Down and Editor->Up key handling is only when
the search box has the focus.
If IDEA fixed the CTRLF CTRLF immediately renewed the last search, then I would use that
to restart the search, since I could then use CTRLN and CTRLP (or Down and Up for non-Emacs
style keymaps) rather than F3 (Find Next) and shift F3 (Find Previous).
Verdict: IDEA +1 better keyboard support.
(4) Highlight Usages option (see screenshot)
Netbeans gives you the option to turn off the highlighting of matches in the Editor.
IDEA does not.
Verdict: +1 Netbeans
(5) Behavior when no match
See attached pictures.
In Netbeans, as soon as you type a character resulting in no matches in the file,
Netbeans BEEPS at you and the text colors changes to red.
In IDEA, as soon as you type a character resulting in no matches in the file,
IDEA changes the background color of the find box to red, but no audio feedback.
Comments: I like the BEEP because as I said above I'm not looking at the find bar
but at the Editor pane, so the BEEP immediately alerts me that there are no matches,
so I can glance at find bar to see if I have a typo.
Verdict: Personal Preference, but IMO, I like the BEEP so +1 Netbeans.
(6) Behavior when reaching end of file.
In Netbeans, when you start a search and there are no more matches before EOF,
Netbeans will automatically jump to the beginning of the file and check for
matches, and jump to the first match. When doing Find Next and there are no
more matches before EOF, Netbeans will BEEP, and then wrap around to the top
and goto the first match.
In IDEA, when ou start a search and there are no more matches before EOF, IDEA
will automatically jump to the beginning of the file and check for matches, and
jump to the first match. When doing Find Next and there are no more matches
before EOF, IDEA displays tooltip ["blah" no found, press F3 to search from the
top], and if you press F3 again, IDEA will then jump to the top and search.
Comments: Behavior is about the same, except Netbeans BEEPs when you reach the EOF.
Verdict: Personal Preference, but IMO, I like the BEEP so +1 Netbeans
(7) Recent Searches list.
Netbeans remebers last searches. You press CTRL+F then DOWN_ARROW to access the list of
recent search terms.
IDEA also remembers search history, and it has three ways to access it:
#1 You press CTRL+F twice
#2 You press CTRLF then CTRLH
#3 You click on the Search History drowdown menu anchor (find icon) in the find bar
Comments: IDEA recent search seems to work better and it is nice they advertise it with
the addition of Search History dropdown menu anchor in the find bar. The only bad thing
about IDEA is they used CTRLF CTRLF to popup the recent searches menu -- the more common use is to immediately search the last search string, as discussed above.
Verdict: IDEA 1 on nicer recent search history menu, -1 for messing up CTRLF CTRL+F
(8) Breaking out of Find mode.
Netbeans acts the same as IDEA (as I documented above in this thread). The
first time you search using CTRL+F, you need to press ESCAPE to break out of
find mode, and return the focus to the editor. When doing Find Next (F3), you
can immediatly break out using an Editor action.
Verdict: -1 for both since both are worse than the original incremental find implementions,
both IDEA's, Eclipse's, and Emacs, because they now require hitting ESCAPE.
(9) IDEA-specific: Navigating Recent Searches List.
I found that IDEA doesn't respect the Editor->Down and Editor->Up keybindings I have for
navigating the recent searches menu. I use Emacs style keymap which tries to avoid having
to hit ESCAPE or arrow keys because they require moving your wrist which slows typing.
I have Down bound to CTRLN and UP bound to CTRLP. In order to navigate the Recent Searches
menu, only DOWN_ARROW and UP_ARROW work.
Verdict: -1 for not supporting Editor->Down and Editor->Up keybindings.
Attachment(s):
netbeans_60b1_find_bar.png
netbeans_60b1_find_bar_no_match.png
7274_find_bar_nomatch.png
Hi Randall,
Thanks for the reply! To be honest: no, it's really not better (IMO), because:
1) It's not standard (I never experienced a program which works like this)
2) It's not documented
3) It's a duplicate of F3 and CTRL+F3.
While I agree that the up and down arrows work much better than F3 and CTRL+F3, I still like idea that pressing enter, which works in every program I know, doesn't damage my code. I press enter to go the next search result without thinking about it. Now I have to start thinking about it again, else my code will be removed. The more I think about it, the more I dislike it.
Erik
PS: It's not only a browser aspect. Word, Textpad, Excel, Eclipse, Wordpad, Notepad, and any other editor I know use this behaviour.
Wow, I never know about hitting ENTER and SHIFTENTER in Firefox. Another one some might not know that I use is CTRLG to Find Next.
Netbeans also supports hitting ENTER and SHIFTENTER in place of F3 and SHIFTF3 as long as the search box has the focus.
I agree with you that IDEA should follow this same convention.
The most flexible solution would be for IDEA to expose all actions as keymap entries.
For example, we have Find Next (F3 by default) which works when the Editor has focus or the search box has focus, but I think we need a "Find Next - Search Field in Focus" that could be assigned as F3, ENTER, DOWN_ARROW, CTRL+G or whatever the user wanted. Then everyone can be happy.
I made an issue for it: http://www.jetbrains.net/jira/browse/IDEA-15079
I agree with you that the most flexible option should be to expose the keys in the keymap entries. I tried changing the keymap, but it has all kinds of side effects, like not being able to refactor (Enter is mapped to search there too...)
I hate to say something so contrasting with the public opinion, but I find the fact that Intellij is working on a redefinition of the search box completely absurd, given how buggy and half-assed some of the (much more important) new features are.
While I don't completely agree on your point (I really like some of the new core features, like Hibernate and Spring support), I'm currently so irritated by the new search plugin that I consider every point against it to be a good point.
Currently, I'm getting superfrustrated with the fact that: a) I don't see the search bar (the visual feedback is so minimal, especially on a huge display with a high (1920x1200) resulution) b) the search-ahead function (already a search when you type) is my current frustration, since I usually use the information in the current editor to know define what I'm searching, and the "unable-to-turn-it-off-searchahead-function" I so annoying, that it ruins my whole IDE experience. I swiched back to an older EAP version (with more bugs/less features) just to get my old search back!! ]]>
Argh!!! ;)
</rant mode>
JetBrains: Give me the old search popup back!! It worked great, and there was absolutely no problem with it
No, really, I don't know what kind of driver is Intellij following.
Their competition pops up products with feature lists such as those: http://www.netbeans.org/community/releases/60/index.html, and while idea doesn't have basic things such as a profiler or a decompiler built in (how about the Eclipse decompiler plugin, which allows one to decompile on the fly while debugging, respecting the original line numbers and allowing one to step in decompiled code?), they lose time with redesigning a basic feature which had no problem at all (while basic usability features such as a text box for pasting a path in the library search dialog are still missing...).
I agree that the new features are nice, what I really don't understand is why they are trying to innovate in fields which pose no problem at all...
I agree. I think this new search thing also distracts a lot from the thing IntelliJ normally is good at: Develop with pleasure. It's nice that IntelliJ tries something new, but it would be great if Jetbrains could do something with the feedback.
Normally, I would say: why spend so much time in the search? It's not that important! Now I've reconsidered that opinion: I noticed it's one of my most used features. I use it more than a 100 times a day, and I'm not comfortable at all with the new User Experience. My first impression was really positive, then started to annoy me, but I decided to give it a chance. At the moment, it's really frustrating me, that's why I switched back (actually, I switch back to version 6. I can develop without the Spring/Hibernate support, but not without the core UI features).
Btw: the NetBeans IDE looks really promising! I really like the integrated profiling and JMeter tools, but I also like the smaller features like the parameter guessing, which just fills in all the parameters which are necesary for a method call, like Eclipse does. Is save a lot of typing!
(Eg: for example, you have a method like:
and you want to use it:
You still have to type all the parameter names, even though it's "obvious" which parameter does what. CTRL+P even shows that what you are typing is really the same as what you are currently typing, but unfortunately, it's doesn't help you a bit).
Completely different story ofcourse, but still: nice that NetBeans has it.
Btw: have you seen this dialog:
http://wiki.netbeans.org/wiki/attach/Java_EditorUsersGuide/CG_Dialog.png ??
It may look a bit familiar....
Ugh, they are copying even the dumb things: they didn't add "generate toString()": I guess they will hope some good soul develops a plugin for a basic functionality, as Intellij does. ;)
:)
I forgot I had installed to toString functionality as a plugin, so I kinda laughed when I found out Eclipse didn't have a standard toString function, but only as a plugin. I was kinda shocked, that after an install on a different machine, I had to find out my toString generator was a plugin too..... :)
Erik Pragt wrote:
> Btw: the NetBeans IDE looks really promising! I really like the
As far as I can tell parameter guessing is just a form of completion.
CtrlShiftSpace in IDEA does the same, does it not? Could you explain
the difference with Netbeans?
Furthermore in IDEA if you enter the variables in the wrong order the
"Suspicious variable/parameter name combination" inspection pops up a
warning. Does Netbeans have that too?
Bas
Hi Bas,
I'm not sure if NetBeans does it the way Eclipse does it, but when you code complete a method in Eclipse, all parameters are automatically inserted. In IntelliJ, you have to manually CtrlShitSpace each parameter. I assumed NetBeans would use the behaviour of Eclipse, since you need less typing for that.
About the second remark: I have no idea, but it's interesting enough to find out. I'm not an NetBeans expert, nor do I plan to be. Besides the search function, I have no problem with IntelliJ, but since it's that's only EAP, I don't see a need to switch.
Hi Erik,
But where do the parameters come from? They're from nowhere. If I have a method m(int x, int y), when I do complete m(), Eclipse will generate m(param1, param2) then you need to change param1 and param2 to the variables name you already have. Is it brilliant? IMO, it's not. Even it isn't intelligent enough to generate m(x, y).
Same with Netbeans AFAIK.
Erik Pragt wrote:
I would be surprised. Since the Netbeans editor seems to be a shameless
copy, I think it emulates IntelliJ IDEA's editor in this case too...
Bas
The parameters are the same as those in the method you're calling.
If you have a method like:
Eclipse will complete this with:
So, when you have a bit of a consistent naming, this works pretty well. If you have something like:
This won't work at all (however, it could ofcourse be possible to do some smart matching)