Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729) Build Identifier: M20090211-1700 When selecting text in a [Java,Text] Editor with SHIFT and ARROW_DOWN, it used to be (in Eclipse 3.41 and previous) that the cursor position of the first selected line was respected for every line added to the selection. This still holds true as long as I don't cross an empty line. Once an empty line got crossed while expanding the selection, the editor forgets the intial cursor position and selects the whole line for every additionally selected line (with SHIFT+ARROW_DOWN). This bug was introduced in 3.4.2 and is still there in Eclipe 3.5/3.5.1. The expected behaviour (remember the initial cursor position) is standard behaviour for Windows application and should be restored. Reproducible: Always Steps to Reproduce: 1. Open a [Java,Text] Editor with multiple text lines and at least one empty line in between. 2. Set the cursor into the middle of the line just above an empty line. 3. Hold SHIFT, then press ARROW_DOWN to select the subsequent lines --> After the empty line, for every line the whole line gets selected.
>This bug was introduced in 3.4.2 I don't this ever worked as you describe. Just checked 3.3.2 (editor and StyledText). > The >expected behaviour (remember the initial cursor position) is standard behaviour >for Windows application and should be restored. Again, this is not true - just checked notepad on Windows 7. Having said that, since we preserve the column position when moving the caret up and down, it would also make sense to preserve it when selecting. Moving to SWT for comments.
closing as wont fix. The same behaviour can be verified in Notepad and Wordpad.
>>This bug was introduced in 3.4.2 >I don't this ever worked as you describe. Just checked 3.3.2 (editor and StyledText). Eclipse 3.4.1 Text Editor supported it. >> The expected behaviour (remember the initial cursor position) is standard behaviour for Windows application and should be restored. >Again, this is not true - just checked notepad on Windows 7. Ok, maybe I should have said "Advanced Windows applications"? It is supported at least in Firefox, Word, UltraEdit (WinXP).
>Eclipse 3.4.1 Text Editor supported it. No it did not (at least not on Windows 7 and I can't believe that it worked on Windows XP Eclipse SDK 3.4.1). Maybe you installed a plug-in with a (text) editor which worked that way but I also doubt that.
You're right, the correct functioning of Shift+Down was due to our own implementation of Block Selection. With Eclipse 3.5, this implementation became obsolete. So this should not be a bug, but a feature request. How do I convert this bug into a feature request? Could also be a papercut (google for 'ubuntu papercuts') if you have such a thing @eclipse? I.e., a nice feature that will be valued by lots of the regular Block Selection mode users (about 300 of them sit over here...).
Sorry, monday morning; My previous comment should read: You're right, the correct functioning of Shift+Down was due to our own fixes of TextEditor (due to our own impl of Block Selection). With Eclipse 3.5, these fixes became obsolete. So this should not be a bug, but a feature request. How do I convert this bug into a feature request? Could also be a papercut (google for 'ubuntu papercuts') if you have such a thing @eclipse? I.e., a nice feature that will be valued by lots of programmers that are used to this behaviour from other "advanced text-based Windows applications" (about 300 of them sit over here...).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
