Community
Participate
Working Groups
Orion 0.2 M6 1. Open a file in coding.html 2. Press Ctrl+F, and search for something that has several occurrences (eg. "foo") 3. Now select something else in the editor (eg. "bar") 4. Press Ctrl+K (Find Next) 5. The next occurrence of "foo" is shown, not "bar". This works differently from the desktop Eclipse editor, where changing the selection affects what will be searched for. I found the Orion editor's behavior surprising.
fixed. Note that I did not change the modal nature of the regexp mode. If you are finding next/previous with a saved regexp pattern, the selection won't alter the mode. This is because: - I don't use the regexp mode and I'm not sure what the user expectation is - I'll err on the side of simplicity for now. (We could check the selection against a stored pattern to determine whether we should stay in pattern mode or are in a different mode)
Reopening because this doesn't behave very well with a case-insensitive search. My buffer looks like this: > var Foo; > // foo > // Foo 1. Starting from line 1, press Ctrl+F and search for "foo". (Note that this is a case insensitive search) 2. You'll get the match "Foo" on line 1. 3. Press Ctrl+K. You'll get the match "Foo" on line 3. Instead I expected it to match "foo" on line 2. It seems that once you hit a match that differs in case, it starts searching for a case-exact match from then on. Since I didn't change the selection myself, I expected it to continue searching case-insensitively.
(In reply to comment #2) > 2. You'll get the match "Foo" on line 1. Sorry, that should say > 2. You'll get the match "foo" on line 1.
(In reply to comment #3) Wait, no it shouldn't. Ignore Comment #3. I wish Bugzilla had an "Edit" button :-/
I'll make a quick fix to be case insensitive and leave it to bug 345033 to give user options.
fixed. We were inferring case sensitivity based on whether the user had typed with case. (Infer that case matters if they do). But...for the case where we enter find next/find previous and we're not already in incremental search mode, we can't rely on the presence of mixed case to infer that case matters. It could have been typed in a dialog or could have been simply selected. This means we're a little inconsistent in how we infer case, but I think this is better. We can let the user have a say in bug 345033
