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 123091 - Extend Selection to Matching Brace action misbehaves
Summary: Extend Selection to Matching Brace action misbehaves
Alias: None
Product: editor
Classification: Unclassified
Component: Navigation (show other bugs)
Version: 6.x
Hardware: PC All
: P3 blocker (vote)
Assignee: issues@editor
Depends on:
Reported: 2007-11-29 22:50 UTC by kirillkh
Modified: 2008-03-12 13:38 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description kirillkh 2007-11-29 22:50:26 UTC
NB6.0 RC2.

class A {
    int b;

1. Position the caret before the "class" keyword.
2. Press shift-End.
3. Press ctrl-shift-[
=> only the code between braces is selected.
Comment 1 Vitezslav Stejskal 2007-11-30 12:24:57 UTC
This works as designed. The action should probably be called something else. I don't have any strong preference for the
current behavior, so if you think it should really 'extend' the existing selection (if something is selected) then
please reopen this report and I'll fix it. Thanks
Comment 2 kirillkh 2007-11-30 14:08:13 UTC
This action used to extend the existing selection up to 6.0, and I have come to use it this way, e.g. when I need to
select a complete block of code to cut-and-paste it somewhere else. But there's another difference between the way it
works right now and how it worked formerly. I believe that before 6.0 it worked as follows ('>' and '<' show selection
start/end, '|' shows the caret):
{|      =>      {>______}|<
|{      =>      no action
}|      =>      {>|_____}<
|}      =>      no action

Right now it works as follows:
{|      =>      {>_____|<}
|{      =>      {>_____|<}
}|      =>      {>|_____<}
|}      =>      {>|_____<}
Which is also useful in a way.

I agree that the way it works right now is a valid use case. So, in order to cover both cases, I suggest to base the
decision, whether to extend the selection up to or after the opposite bracket, based on whether the caret is positioned
outside or inside the bracketed scope:
{|      =>      {>_____|<}
}|      =>    >|{________}<
|{      =>     >{________}|<
|}      =>      {>|_____<}

If the above suggestion is too complicated or if it is thought that some users won't like it this way, I wouldn't object
having a different action that exactly reproduced the old behavior. 

Thanks a bunch.
Comment 3 Vitezslav Stejskal 2007-12-03 10:52:30 UTC
I think this makes sense. It should be fairly easy to change. As I said I didn't have any strong feeling for the way how
it was implemented. I just tried to keep it as simple as possible. Prior nb6 braces matching wasn't able to recognize
braces standing on the left side of the caret. This has been changed for nb6 and I had to come up with some reasonable
behavior for the 'Extend selection ...' action.
Comment 4 Vitezslav Stejskal 2008-02-20 13:50:07 UTC
changeset 7ae1cbf5bd88 in main
Comment 5 kirillkh 2008-02-25 20:50:47 UTC
Using build 20080224134815, I can see that the second suggestion(regarding jumping based on caret position relative to
bracket) has been implemented, but the original problem still exists. Namely, instead of extending existing selection,
the action selects the area between brackets.
Comment 6 Vitezslav Stejskal 2008-02-26 13:12:29 UTC
Ehrrm, I should have read the issue more carefully. Anyway, could you please try again :-). Thanks

changeset 1b418c30fb3e in main
Comment 7 kirillkh 2008-03-02 14:03:51 UTC
Works fine now, thanks :)
Comment 8 kirillkh 2008-03-04 19:55:13 UTC
Another bug report.

Test case:
  {|> asdf <fdsa }

Pressing ctrl-shift-[ produces:
  {> asdf fdsa <|}

But I expect:
  { asdf >fdsa <|}

A similar problem occurs every time the selection begins inside the bracketed scope. In particular, the following cases
are also problematic:
  |>{ asdf <fdsa }
  { asdf >fdsa <|}
  { asdf >fdsa }<|

Again, I expect the described behavior, since this is the way it worked formerly, but also because it seems more to me
adequate and useful (I actually use this way of selecting things).
Comment 9 kirillkh 2008-03-04 19:59:22 UTC
... seems to me more adequate and useful ...
Comment 10 Vitezslav Stejskal 2008-03-05 11:34:23 UTC
Well, again I have no strong opinion here and it's definitely a matter of personal habits, but in this case I would
advocate the current behavior. IMO it's more practical and consistent if the action selects the whole text between
brackets. If you still think it has to be changed, please reopen.
Comment 11 kirillkh 2008-03-05 14:32:43 UTC
I have no intention to fight over this, but honestly I still think it should be changed. Formally, this is a regression,
but my main reason is that with the way I want it to work, it is more convenient to cut all the useful code out of this:

public void test() {
   // line1
   // ...
   // line5

   /* useful code starts here */    

   // ...
   // line100

   /* useful code ends here */

In my opinion, the natural way of cutting the section you need out of this method is:
1. position cursor at the start of the useful section
2. ???
3. ctrl-x

With what I suggest, p.2 above can be done as:
1. hold shift
2. select up until the opening bracket
3. ctrl-shift-[

In your way, however, this won't work, so to keep the number of keystrokes low, one will have to do something like this:
1. position the cursor at the END of the section
2. ctrl-shift-[
3. hold shift and select down to the start of the useful section

I consider this less natural and less convenient (I want to start selecting text right after discovering the start of
the section).

A more general way to see the advantage of what I suggest is to consider the position before pressing ctrl-shift-[ a
piece of information; if after pressing ctrl-shift-[ this information is lost, you lose something you might want, in
which case you'll have to navigate to it again; if it is retained, you don't lose anything.
Comment 12 kirillkh 2008-03-05 14:58:53 UTC
Problem #2:
looking further into the example, in your way the selection will span from the closing bracket up to the start of the
useful section:

public void test() {
   // ...
   |>/* useful code starts here */

   /* useful code ends here */

If you press ctrl-x at this point, this will transform the remaining code into:

public void test() {
    // ...

This breaks formatting, so you'll have to manually reposition the closing bracket. In my way, however, it will be enough
to press the Home key before cutting to avoid formatting problems (which is what I always do).

Problem #3:
I have just realized that your way won't work at all in case the useful section doesn't start or end strictly at the
bounds of the method body.
Comment 13 Vitezslav Stejskal 2008-03-06 10:37:46 UTC
> I have no intention to fight over this, ...

Neither have I. :-) Thanks for the further information. I can see now that I am much less concerned about this than you
are, so I will change it to suite your needs. For me the natural way of cutting the section in #2 would be:

1. hold shift
2. select down until the end of the useful code section

I would not even think of using brackets-based navigation in this situation. But that's just me. :-)
Comment 14 kirillkh 2008-03-06 13:14:50 UTC
Seriously, though, I use it all the time, that's why it hurts, when it stops working. You just discover these tricks
once and then use them automatically.
Comment 15 Vitezslav Stejskal 2008-03-12 13:38:51 UTC
I pushed the changes. If you could, please verify in a dev build. Thanks