Find Bar UI - for everyone
Okay, going to try to keep this short and simple(both being subjective). Basically, I went through the last Find Bar thread and couple of JIRAs(but not all), and tried to come up with a list of options, suggestions, and discussion points, so that, hopefully, we can reach a consensus on a way to make the new find bar work as well as it can for everyone. This is just a bit of brain storming, so, well, you know how that goes....
So, please, if you can, keep an open mind and keep on topic, and lets see if we can come to some mutual agreements. Let's assume the new find UI is here to stay and build constructively on that.
And, if you already have a JIRA opened for one of these, please posted to this thread.
The following, I would say, would be set in Setting, under Editor, on the Behavior Tab. They are for general behavior characteristics of the find bar: when, where, and how.
Mode:
=====
1 - Default - What is currently does today - Appears for the current tab and stays there until you close it(ESC, click the X)
2 - Persistent: Is always there, on all edit frames/tabs. Ctrl F simple takes to your the text entry box. ESC and clicking the X(which probably would not be there) don't make it go away.
3 - Transient: As soon as it loses focus, it goes away; usually after the user has pressed Enter or clicked Find Next/Prev.
4 - Pop: Back to the old pop-up window.
Note, item 4 might not be an option, but simply an available key binding.
Focus on Find:
==============
1 - Find Box/Bar - basically the default as it is now, the cursor stays in the find box.
2 - Editor window as soon as Enter/Find Next/Find Previous is used - That way, you can begin editing without.
Focus on Find is not available for Transient Mode.
Location:
=========
1 - Top of Edit Window
2 - Bottom of Edit Window
3 - Toolbar(for those that have room)
4 - *Floating - Remember Position - Always appears in the same spot when opened
5 - *Floating - Above/Below cursor(only available when Mode is Default or Transient)
4 and 5 might be a bit extreme, but it might solve the problem for those that liked the old pop-up and don't want the find bar attached to their edit/edit windows. In short, using 4 or 5 in the default or transient mode gives behavior somewhat like the old find popup.
5 might work well for those who use incremental search more often than regular find.
The following are for the find bar(and some already exist).
Find Bar Options:
=================
- Regex
- Case Sensitive
- Whole Word Only
- Highlight All - If turned off, then it just goes from match to match, no highlighting or marks.
- Scroll to match while typing - If this option is turned off, idea does nothing until the user presses Enter or Find Next/Prev
- *Find In "Selection"
Other:
======
- Ability to perform a Find All. This could be a button next to the Find Next/Prev buttons
- Key Bindings specific for the find bar(when it has focus), such as using Ctrl-R to toggle Regex, instead of having to click with a mouse.
- I think you could make the find bar a little more compact if you replace the check boxes and text with toggle buttons(with tool tips), just like those you used in the project or structure panes.
Lastly, a few general issue/concerns I read about, but did not have any additional thoughts on. So, if you have any additional thoughts on these, now is the time.
Issues:
=======
There were some issues expressed about Regex. Not sure if they have been addressed or not.
Concerns about Incremental Search. Again, not sure if they have been fully addressed.
Anything else I forgot.
Closing Thoughts:
=================
As a final thought, because, depending on their implementation, there is a risk of the find bar getting too busy; though using toggle buttons instead of check boxes and text would help.
However, it might not be a bad idea to have an option on the Find Bar UI(like and Advanced button) that points the user to the old Find popup or an updated version of the Find In Path, where maybe some of the less used options would be located.
Though, if that was done, I would love to see the Find popups made non-modal; not even sure why they are modal.
Message was edited by:
zmbs - Added Find In "Selection" as a find bar option. Also added some Closing Thoughts
Please sign in to leave a comment.
+1 - that seems to cover everything ;)
Nice summary on the various discussion points.
I personally like the new find bar for 90% of my searches. 10% of the time I do miss the old modal dialog. Here are some of my comments:
Find Bar Options: I would love to see the "toggle highlighting" and "toggle auto-scroll" features added.
Focus on Find: I think that it would be helpful to have the focus return to the editor upon hitting enter (at the very least) and find next/previous
Location: I'm happy with where it is at. But given the amount of discussion on it, perhaps an option to move it to the top or bottom of the pane would be nice.
Mode: I like the current Default (i.e. #1 in your list). I know some people would like to see #4, the return to the old popup modal dialog window. You comment about maybe making it a key binding. I have a similar idea.
Given the amount of discussion that is going on about the find bar and modal window, I just suggested in another find bar thread that perhaps JetBrains could bring back the old modal dialog window mapped to ctrl-F, and map the new find bar to alt-F3 as a new & improved incremental search. (Users could remap them if desired.) If "toggle highlighting" and "toggle auto-scroll" were added to the find bar, the operation of the old incremental search could be mimicked. I think that would make most everyone happy, and give us the best of both worlds: two great find utilities that users can tailor to their way of working. What are other people's thoughts on that? What about JetBrain's thoughts/comments?
I agree - it's better to provide the new Find bar as an additional feature than as a replacement. I was quite comfortable with the old Find dialog, and it still rankles that I was forced to adopt the new Find bar - and even though it covers most of the basic requirements, I still find it awkward at times. I'd like to be able to choose between the dialog with all the options it remembers between invocations, and the new bar with its subset of options. It would also be nice to be able to position it wherever I want - docked or floating.
Updated original message to add Find In Selection to the Find Bar options(credit to Mark Vedder on that) and add a few additional thoughts(again, a little brain storming).
I agree. If we can find the right balance of options, we could make most people happy.
That is one of the reasons I added the transient mode. In short it could be used to make the new find bar work like the old pop-up and the increment search(especially if the find bar floats), by having it go away on its own.
One other possibility I thought about, to possibly reduce clutter, is to hide some of the options, which could be exposed on an expanded find bar(again a bit of BSing --- Brain Storming). Though, I am not sure how that might work for everyone. For use mouse users, it would be similar to other apps where we can make certain tool bars hide/unhide and/or expose advanced features. But, it might be a pain for the regular keyboard users.
But, I would like to hear JB pipe in on this.
Well, I think access to the old Find should still be there; through a keyboard mapping at minimum.
But, if JB is set on having the new Find UI for 7.0 and up, then it probably should be the default for new users.
I see potential in the new Find Bar, but it is a bit awkward, like you said. Such as, not being able to go straight to editing after the first find is definitely disorienting.
And, I think you may be onto something, where more advanced or less used option would be in the pop-up and the find bar being a subset of the most commonly used features/options.
Though, I could see a battle on what is considered commonly used vs what is more advanced/less commonly used. :)
+100
i'm not interested in new find bar, it's awful for me
it's great that many people like the new one
but please return the old popup window as an option or other key binding
Find in selection could be done like this: http://www.jetbrains.net/jira/browse/IDEADEV-21736
"When a text is selected, the search should only find results within the selection.
Furthermore, the selection should not be cleared."
This way, we wouldn't clutter the interface with an extra option and it seems intuitive enough.
Please vote (shameless plug).
I think it needs to be modified just slightly, in that it only does a find in the selection, so long as the select text is not exactly the same as the text that is being search for.
In the following, denotes selected text
Let say you are selected the following below and paste it to the find box(the selected text is the word 'some'):
+private void Method(String someString, int someInt)
{
// some code starts here
// some code stops here
}
+
In this case, you do not want to search within the selection, since it is exactly the same as the text entered in the find box.
However, let say you selected as follows(the entire method) and search for the word 'some':
*+
[private void someMethod(String someString, int someInt)
{
// some code starts here
// some code stops here
} ]+*
In this case, you would want to do a search within the selection.
I noticed that it's still possible to get the old find dialog in build 7330. I suppose that this is a bug, but in any case they still have not yet completely removed the old search. :)
If you just started IDEA and have not yet used the find command, pressing F3 will open up the old find dialog (see picture).
Please do not remove it even after I reported this - make it an option to use the old or the new find. Or alternatively, let somebody make a plugin for bringing up the old find dialog.
Attachment(s):
old-find-after-F3.png
If I recall correctly from the discussion that arose immediately after the new find bar was introduced, JetBrains agreed to make it possible to access the "classic" modal find dialog and bind it to a keyboard shortcut, if so desired.
Randall Schulz
I thought that was for incremental search, at least in part.
For people that used Find dialog before, the new find bar seems better except the find bar sticks around if you didn't cancel it by hitting ESCAPE. That is introducing unnecessary clutter.
It works much nicer in Netbeans 6.0b1 where as soon as the find bar search box loses focus -- e.g. you click in the editor or click on a different tab or click anywhere else for that matter -- the find bar disappears.
I think that is the way to go since 99% of the time if you clicked somewhere else, that means you are done with the find bar.
Find bar should be disposed as soon as the search box loses focus.
http://www.jetbrains.net/jira/browse/IDEA-15600
This inline find bar is replacement for the modal find dialog, but it doesn't replace Incremental Search.
Once Jetbrains stopped auto-remapping "Incremental Search" to this inline find bar, I calmed down about
it.
But I think they should go further and restore the Incremental Search back in the Edit
menu. The Incremental Search is actually a more productive search mode than using
the inline find bar which has additional complexity of focus in the search box/focus in the editor
and requires an extra keystroke to return focus to the Editor.
Am I the only person that ever used this Incremental Search before? Jetbrains acts like nobody uses this feature. If you use it like I do, I would appreciate a word of encouragement. ]]>
I'm finding Eclipse and Netbeans are often supporting basic editing much better than IDEA,
which is frustrating because IDEA clobbers them on advanced features.
I would think IDEA should match both of those on all editing features, since most new
potential IDEA customers are former Eclipse/Netbeans customers now going forward.
Getting specific in regards to this Incremental Search:
Eclipse advertises Incremental Find Next and Incremental Find Previous in
the Edit menu. (See attached picture which shows default keybindings. See
alternate picture for the keybindings if you switch to Emacs keymap.)
http://www.jetbrains.net/jira/browse/IDEA-15601
Eclipse allows you to start the Incremental search in reverse by pressing
the Incremental Find Previous keybinding. IDEA only has "Incremental Search".
So you have to start the search forward and then you can use UP_ARROW or Editor->Up
keybiding to go in reverse.
http://www.jetbrains.net/jira/browse/IDEA-15602
Once in Incremental Search mode, Eclipse allows you to press Incremental
Find Next and Incremental Find Previous repeatededly to goto the next match.
Once you get used to this, this find mode is simplicity because to search forward
you type CTRLF (CTRLS for emacs keymap) and then press CTRL+F again to goto
next. There is no CTRL+F and then F3/RETURN to goto the next. And then you can
press any editor action like RIGHT_ARROW,CTRL+W,etc. to immediately break out and
start editing rather than having to reach up and hit ESCAPE first.
http://www.jetbrains.net/jira/browse/IDEA-15603
Eclipse displays the pattern typed by the user in the status bar rather than in
a little window at the top of the Editor, which is the same as Emacs. This last
item I don't care so much about.
(See screenshot.)
In summary, Eclipse replicates Emacs I-Search mode almost to the tee, while IDEA's
implementaiton is only partial. (See http://www.gnu.org/software/emacs/manual/html_node/emacs/Incremental-Search.html#Incremental-Search)
Also, specific to IDEA, the Incremental Search should also use tooltips to
warn about reaching end of buffer like the new inline find bar does.
The inline find bar will display a tooltip
"pattern" not found, press F3 to search from the top(bottom)
when you reach the start of end of the buffer and pressing Find Next again will
wrap to the top(bottom). In Incremental Search, when you reach the last match,
it does nothing.
http://www.jetbrains.net/jira/browse/IDEA-15604
Attachment(s):
eclipse_34m2_edit_menu.png
eclipse_34m2_edit_menu_emacs_keymap.png
34m2_inremental_search.png
34m2_reverse_inremental_search.png
I almost never used "regular" search, relying only on incremental search for same-file searchs, and "find in path" for more complicated cases.
The new search bar might look different, but behaves exactly the same as incremental search did -- since most of the time I won't even be looking at it, it's OK. As long as ALT+F3 starts incremental search, arrow up and arrow down works, F3 works for next match, I'm happy.
You gotta be kidding. Eclipse and NetBeans (hahaha) might have a feature or two missing in IDEA, but overall basic code editing in IDEA is a lot more pleasing. I particularly hate Eclipse's fetish for multi level menus and detachable views.
And how different is this from the "Find..." item in IDEA's "Search" menu?
OK, one point to Eclipse. But this is far from being a big problem. Couple with your next point, this isn't a problem, but a different choice. I love the fact that in IDEA I can just use UP and DOWN to navigate between search results, something I can't do in Eclipse.
Eclipse might be handier and easier to use for diehard Emacs fans, but saner people have always used vi anyways.
Really, I don't see what the old incremental search did that the new find bar doesn't. And IIRC, the old incremental search used to display tooltips anyway.
Hm.. I'm surprised that you say you used incremental search exclusively over Edit->Find, and you
think there are no differences between the new find bar and incremental search.
Big difference #1 is you can break out of incremental search without hitting ESCAPE key! When
Jetbrains remapped Incremental Search to this find bar, I felt like my cursor was trapped in a
prison cell (that search box), and I had to hit ESCAPE to break him out. There are more differences
too, which I have already discussed, but that is the most important one.
I remember when I first switched to IDEA from XEmacs/JDE, I remember that the Incremental search
didn't support hitting CTRL+S again in place of Find Next, but I got used to it, and I remember
that it didn't suport CTRL+R (Reverse Incremental Search). But the main thing was IDEA's I-Search
did still let you break out of the search by pressing any other navigation or edit keybinding, and
that was the most important feature.
Now, if Jetbrains hadn't remapped I-Search to inline find bar, I probably wouldn't have noticed
this new inline find bar since I dont' use Edit->Find, but since they did, I did notice, and now
that they've stirred up the hornet's nest, I might as well let it all out.
Everyone is currently hot on this 'inline find bar' after Firefox has made it popular, and we see
Netbeans and IDEA now basically copy it verbatim. The thing is Firefox is not an editor, and so
what works best there is not necessarily the best in an editor.
I originally thought Jetbrains was going to innovate and create something better suited for an
Editor, and I gave some suggestions, e.g. maybe make the search box not have focus, similar to how
the incremental search doesn't let the focus leave the editor, but Jetbrains were beholden to
copying the Firefox inline find bar. I also filed jiras asking that they at least support hitting
CTRLF CTRLF to restart the last search (instead of popping up menu of last searched) (IDEA-15131 -
Won't Fix) Even worse, now they think this new inline find bar exactly duplicated I-Search, and so
they want to remove that feature!
To quote Jetbrains from the IDEA-15601: IDEA should restore the "Incremental Search" in the Edit menu.(Won't Fix)
"We don't see any sense in advertising a deprecated feature. If you do want such a menu item for yourself, you can add it using Customizations."
"As you can see from all the discussions on this topic, which exactly way of editing is the best is a subject for much debate. We do not plan to overload the product with options that would allow to match exactly the behavior of NetBeans, Eclipse or some other product."
So, here we are with Jetbrains enhancing Edit->Find to use this inline find bar model, and then
using that as an excuse to get rid of their I-Search which is tried-and-true since Emacs, and
replicated perfectly in Eclipse, MyEclipse, JBuilder 2007 (now uses Eclipse). Oracle's JDeveloper
also has incremental search and reverse and supports all the keyboard behavior except it doesn't
let you break out without hitting ESCAPE. All those users that use Eclipse variants are potential
IDEA users, and I bet many of them are using that incremental search.
I really really doubt I'm the only developer who appreciates the I-Search behavior, and I am
personally dumbfounded that Jetbrains thinks that it is now deprecated by this inline find bar. If
Jetbrains is spending so much time improving Edit->Find and introducing Show Usages variant of Find
Usages, you'd think they could spend a day and fix up their I-Search so it matches the accepted
convention.
Let me recap:
1. Don't remove features from your product. (Duh!)
2. Don't remove features from your product which your competitor also has, and does even better than you did.
Corrollary to 2.: Improve those features where you competitor is better than you.
Between this 'inline find bar', the unremovable 'xml/jsp/html breadcrumbs bar, the promising yet
totally unpolished show usages, etc., I feel like Jetbrains is "out to lunch" on this release as
far as usability is concerned. I can only hope that most of this is due to the developers getting
spread too thin with all these other non-editor/core/java features like hibrernate support, spring
support, maven, etc. this release.
To end this on a good note, here's five new things in Selena which I make use of every
day. These features are 100% goodness:
1. Compile/Find/Inspect in the background!
2. All the Textfields support your keybindings like CTRL+BACKSPACE and camel case navigation.
3. Fix All 'x' problem Intention
4. Debuugger Auto variables mode.
5. 60+ new inspections (and now with that New in 7 button you can actually seee them in Errors dialog!!)
I used to break out of the old incremental search using ESC anyway, and I have the feeling that I'm not alone.
The other way to break out of incremental search was using the mouse to click somewhere on the source code. The new behaviour is actually an improvement for me: now I can start searching, click on the source code and change something without losing my search term.
No, please do remove features. I actually think there are a ream of other unused or obsolete features in IDEA that should be removed as well. If you don't ever remove anything, even when you add something new that completely replaces an old feature for all practical reasons, you end up with a bloated, confusing product.
+100 as well
It breaks the editing flow... I find myself working around the new find
bar more than working with it, unfortunately.
Mishael wrote:
Well, I have a feeling both of you are not alone in the way you prefer to work, and that there are many others that work in completely different ways yet(I know I am one).
And, I would tend to agree that older functionality should be removed.
But, I also think that they need to build some flexibility into their new features, instead of using the cram-it-down-the-customers-throat-because-we-know-what-is-best-for-you strategy. Yes, that is a bit harsh, but, sometimes, that is how it feels.
I skipped V6 because there was nothing in there that really warrented(for me) making an upgrade. I like V7, but I am still a bit on the fence about it, and will probably evaluate all of my options before committing to a purchase. I just don't need all of the bleeding edge stuff, but I do need a good JAVA and J2EE IDE that works well with me; and big plus if I could use it to edit other project related files without causing me more headaches.
BTW, I did add a couple of comments to your JIRA.
It hasn't been removed. The old popup is still there, just not bound to any key. You can edit your keymap and bind ALT+F3 to the old action.
-101
Although it feels a bit like we've had this discussion before (dejavu?), I personally think it's quite annoying to have the search result in straight editing. I caused me to lose the words I was looking for, eg: if I was looking for the word private, I found the word, and I started typing, causing the word private to be removed. Not really what I expected to happen, and quite different from other search-enabled programs like Eclipse or Microsoft Office.
So I'm quite happy with the current behaviour, except that I would be even more pleased with the old behaviour. I still think the find bar is not visible enough, especially on huge monitors, and it's strange to switch between tabs and sometimes find an open search bar on top of your screen.
But, to be honest, I've given up on the search thing. There was a lot of noice from the community and a lot of silence on JB's part, but at least the search isn't as annoying as the new search was before.
It's still there? Could you explain me how to find it? I've searched for 'find' as well as 'search', but I haven't been able to find it.
Hello Erik,
Keymap | Other | Incremental Search
--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
This does not work.
When I attempt to use a short cut key assigned to "Keymap | Other |
Incremental Search", I get a weird little popup that says "Search For:"
that looks like a tooltip located where the find bar normally is, but
the popup doesn't do anything.
Testing in IDEA build 7361
Dmitry Jemerov wrote:
>> It's still there? Could you explain me how to find it? I've searched
>> for 'find' as well as 'search', but I haven't been able to find it.
>I get a weird little popup that says "Search For:"
That is the old incremental search. If you start typing, you will see what you are typing appear after the "Search For:" and the first instance of the pattern highlighted in the editor, with it changing as you type more. (Just like if you start typing something, like a file name, with focus in the Project tool window).
Are you thinking of and looking for the old Find dialog modal window? If so, I believe that is not available for mapping to.
uh.. yeah.
Mark Vedder wrote:
>> I get a weird little popup that says "Search For:"
So how do I get the old Find dialog modal window?
Arthur Blake wrote:
>>> I get a weird little popup that says "Search For:"
>>
>> That is the old incremental search. If you start typing, you
>> will see what you are typing appear after the "Search For:" and the
>> first instance of the pattern highlighted in the editor, with it
>> changing as you type more. (Just like if you start typing something,
>> like a file name, with focus in the Project tool window).
>> Are you thinking of and looking for the old Find dialog modal window?
I filed recently two issues related to "Highlight usages in file" (CtrlShiftF7) which does not work the way it was in IDEA 6 and which result in degraded usability. These appear to be side effects of the new search bar. These disturbed me very much and lowered my productivity when I did a couple of hours XML editing.
Highlight usages in file (CtrlShiftF7) does not highlight multi-line selections (like IDEA6 did)
http://www.jetbrains.net/jira/browse/IDEA-15754
Highlight usages in file (CtrlShiftF7) does not allow jumping (F3) between all highlighted usages, when many different texts are highlighted (like IDEA6 did)
http://www.jetbrains.net/jira/browse/IDEA-15760
Arthur Blake wrote:
Judging by the stark silence... I guess you can't....
Please bring back my old friend, the old modal find dialog!
I can still access it right after starting IDEA 7.0 (via another IDEA
bug) by pressing Ctrl-L , but only if I don't run any other searches
first-- so I know the code is still in their somewhere!
but... I can't access it again after running my first search...
The new find methodology is partially modal depending on what mode it's
in, this breaks common sense user interface standards by not having a
good affordance that it's working this way and thus confuses a lot of
users and breaks their editing flow...
because searching is so central to editing-- this substantially reduces
coding productivity and pleasure.
Please, at least make the old modal find dialog an option that can be
assigned via a shortcut!
EAP'ers, if you care about this, please vote for!
http://www.jetbrains.net/jira/browse/IDEA-15863
thanks