This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 66037 - Make ^[ smarter
Summary: Make ^[ smarter
Status: RESOLVED DUPLICATE of bug 95126
Alias: None
Product: editor
Classification: Unclassified
Component: Key bindings (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: issues@editor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-05 18:59 UTC by jxt
Modified: 2007-11-05 13:40 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jxt 2005-10-05 18:59:45 UTC
The ^[ command to find a matching brace or paren is nice, but it could be 
nicer. Currently, the cursor must be just past the opening or closing brace or 
paren. Especially for closing braces that appear on a line by themselves, or 
on a line with nothing else besides comments, ^[ should be smart enough to 
work if placed anywhere on that line, and most especially if placed in the 
white space before the brace. The same goes for whitespace or comments after 
an opening brace.

For example, in
<code>
try { // some | comment
    // code here
}
catch (...)
</code>
If the cursor is in the location marked by "|" above, then ^[ should jump to 
the closing brace.

Basically, anytime that the opening and closing braces are unambiguous, make ^
[ do the right thing. Obviously if code is formatted like this

<code>
    if (...) { // explain the if clause
        ...
    } else { // explain the else clause
        ...
    } // final comment
</code>

then a cursor in the middle of the word "else" is ambiguous. But if it is 
anywhere before the opening brace of that line, it's obvious what ^[ should 
do. Same if the cursor is anywhere after the opening brace of the else or 
anywhere after the closing brace, within the final comment.
Comment 1 Vitezslav Stejskal 2007-05-10 06:56:29 UTC
Issue #95126 covers all of this.

*** This issue has been marked as a duplicate of 95126 ***