Community
Participate
Working Groups
In the Java editor, select several lines of text, moving up. (That is, the cursor should be at the top of the block when you've finished selecting.) Press 'Tab' The lines all indent, and the cursor moves to the bottom of the selection. Block indent should not cause the cursor to move.
Current behavior seems to be standard for our operations that modify blocks of text. For example, selecting "up" and then using paste to replace the selection with another block of text also leaves the cursor at the end. We could argue that either behavior is correct, but in truth if we haven't changed the behavior in >5 years, it's not going to happen now. Particularly, since other code may be relying on how it currently works. Closing for lack of activity. Please re-open if we intend to address this.
*** Bug 302539 has been marked as a duplicate of this bug. ***
*** Bug 275982 has been marked as a duplicate of this bug. ***
Any chance of reopening this? There have been a few dupes filed recently...
>Any chance of reopening this? No plans to change this at the moment. There's no business case and other editors also behave that way.
Really? What are some examples of other editors with this behavior?
FWIW the Borland C++ IDE is an example of the way it *should* behave, when you indent text there the cursor doesn't move. I've been using Eclipse for many years yet coming from Borland I still get a surprise when the cursor jumps after indenting text. I think the problem is that after you select some text, if you move the cursor immediately it behaves one way, yet if you press tab then move the cursor it behaves differently. Currently if you stare at a block of text you don't know how the cursor is going to behave unless you know whether the tab key has been pressed or not. I think pressing tab should not change the behaviour of the arrow keys. Sure, issues like this are only minor, but when you spend all day using Eclipse it's the little things that start getting to you... (A little off-topic but a related issue is when you press Ctrl+A to select-all. In the Borland IDE the cursor doesn't move, but in Eclipse it jumps to the start or end of the file, which is another pet peeve of mine - since Ctrl+A is so close to Ctrl+S, I often lose my place in the file after attempting to save it.)
>Really? What are some examples of other editors with this behavior? e.g. UltraEdit. Besides seeing the caret move is there any real usability issue you have?
Well, it slows down my development work because I spend more time than I need to scrolling around with the keyboard. I'm one of those people who like formatting my code by hand, so I do spend time indenting blocks of text in and out. When you're working your way through a file it can really become annoying. But I'm afraid that's all it boils down to - fixing this would lower my stress levels :-)
We would accept a patch, so if it really bothers you... ;-)
Okay, I'm prepared to take your challenge ;-) But I've never hacked on Eclipse before, can you give me a hint which file to start looking at once I've got the code?
The affected code is most likely in the 'org.eclipse.jface.text' project. Take a look at - org.eclipse.jface.text.TextViewer.ViewerState.connect(IDocument) - org.eclipse.jface.text.TextViewer.ViewerState.restore(boolean) The hard part is to make sure other scenarios aren't broken.
Have a look at Bug 289808, where I mention what I believe is the root cause of this. (it is in TextViewer.ViewerState.connect(), as Dani says)
*** Bug 289808 has been marked as a duplicate of this bug. ***
Reopening since someone wants to work on this.
>Have a look at Bug 289808, where I mention what I believe is the root cause of >this. (it is in TextViewer.ViewerState.connect(), as Dani says) Thanks for reminding me on this one.
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.
> 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. Very well. :D Currently on Eclipse 2020-03 Version: 2020-03 RC1 (4.15.0RC1) Build id: 20200305-1156 OS: Windows 10 Pro x64 (version 1909, Build 18363.719) Per original post (OP), selecting several lines, dragging in the direction from bottom to top, then pressing the TAB key shows that the text cursor is still located at the top. Behavior seems to be what was expected per OP. I'm assuming this is what the issue is to be tested against. Per Windows 10 behavior, the text cursor moves to the top if the user presses the LEFT ARROW key after pressing TAB key, otherwise, the text cursor will be at the bottom if the user presses the RIGHT ARROW key after pressing TAB key. Same with CTRL+A to select all text then TAB key. Text cursor is at the top if LEFT ARROW key is pressed. Text cursor is at bottom if RIGHT ARROW key is pressed. Haven't tested this on Linux (Ubuntu) yet. Don't have Mac OS X hardware.
