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.
|Summary:||[68cat] Inconsistent behavior of selection with Shift Line Left/Right|
|Component:||-- Other --||Assignee:||Milutin Kristofic <mkristofic>|
|Issue Type:||DEFECT||Exception Reporter:|
|Attachments:||The Screenshots. This was found with build 200707270000, by the way.|
Description matthies 2007-07-30 17:43:14 UTC
See the screenshots in the attached image. When selecting a couple of lines, then when the first line has no whitespace at the beginning (screenshot A), Shift Line Right (Alt+Shift+Right) indents the selection on the first line (screenshot B). This is inconvenient for copy&paste. When on the other hand the first line does have whitespace at the beginning (screenshot C), then Shift Line Right works as expected (screenshot D), i.e. it does not indent the selection on the first line, but then unshifting with Shift Line Left (Alt+Shift+Left) introduces an indent (screenshot E). Expected behavior: When whole lines are selected, shifting the lines left or right should keep the whole lines selected and not introduce any indent.
Comment 1 matthies 2007-07-30 17:44:53 UTC
Created attachment 45888 [details] The Screenshots. This was found with build 200707270000, by the way.
Comment 2 Jiri Prox 2007-07-31 07:34:00 UTC
Reproducible, but IMHO it is not so serious
Comment 3 matthies 2007-07-31 12:54:31 UTC
I don't know about serious, but it's highly annoying. I happen to use shifting quite often when moving code around with cut&paste, or to indent code before copying it to an e-mail, etc. This defect almost always means I have to fix the indent after pasting, which is tedious.
Comment 4 Miloslav Metelka 2007-07-31 17:03:10 UTC
This will require some extra code to check whether the whole first line is selected and fix the selection after the reformat. BTW format after paste - isn't paste formatted on ctrl-shift-v sufficient?
Comment 5 matthies 2007-08-14 23:49:00 UTC
Please note that pretty much all other text editors have the behavior I described as "expected" here. I just checked Visual Studio, UltraEdit, Vim, Joe, to name a few. Where they differ a bit is in the behavior when the beginning or end of the selection is not at the start of the line (I found Visual Studio's behavior most useful there). Ctrl+Shift+V is not a real solution: - It doesn't help when pasting into a different application. - It doesn't help when pasting into a different file type (for when example pasting code snippets into a changelog or todo file etc.). - It doesn't help when you're working with some code that uses a different formatting convention than the one configured in the options. - It doesn't help when the formatting is more complex than what can be defined with the formatting options (multi-line statements aligned on certain operators, for example). - But most importantly: It's an extra hoop to jump through that is not necessary with other editors I've been working with for the last 15 years or so.
Comment 6 Jiri Prox 2007-10-08 13:04:38 UTC
*** Issue 117957 has been marked as a duplicate of this issue. ***
Comment 7 athompson 2007-10-08 14:34:47 UTC
yup. highly annoying.
Comment 8 David Strupl 2009-03-31 15:50:49 UTC
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
Comment 9 Quality Engineering 2009-11-02 11:02:51 UTC
NetBeans.org Migration: changing resolution from LATER to WONTFIX
Comment 10 athompson 2009-11-16 09:10:31 UTC
Comment 11 matthies 2009-11-16 11:50:34 UTC
@athompson: This is part of the netbeans.org migration, see http://wiki.netbeans.org/NBorgMigration. Reopening.
Comment 12 Martin Balin 2016-07-07 07:27:59 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss
Comment 13 athompson 2016-07-07 16:07:43 UTC
Still annoyingly relevant.