Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1. Open a text editor 2. Move cursor to the line you want to join with the next line 3. Press CTRL+ALT+J to join lines The lines are now joined and the cursor is positioned at the end of the joined line. Expected: The cursor should be positioned at the joining point of the two lines. More information: Positioning the cursor at the end of the joined line is often counter productive, as quite often I want to continue typing stuff at the point of the joined lines. When cursor would be positioned at the joining point, I can still move my cursor easily to the end of the joined line with a single key press, while as moving cursor back to the joining point is often much more work than it would need to be. (This is also the default behavior of the VIM's Join Lines command, which I have grown rather accustomed to :) )
sorry for bugspam - the subject line was incomplete ..
Note that you can join several lines at once. The only possible alternative we could discuss would be to leave the selection as is but for now we won't change this as we did not get any similar complaint so far.
Indeed, but this could possibly be solved by keeping placeholders for all removed line separators. This way one could tab through all line separators, until reaching eol. This would work much like code templates, allow easy access to Another way (a bit more hackish) would be to use the special case for joining 2 lines and keeping current behavior for larger line joins...
Sure we could do this but seems like an overkill to me. And even if we'd had markers for the split points, the default would probably be end-of-line since it's really a user preference whether to keep the existing selection or place the caret at end of line or first split point. As said: we won't work on this.
I could try working out a patch to this, if you guys don't have time to do that. As far as preferences and default behaviors go, I do not think we need yet another preference just to tell how to join lines... IF the "new" join lines behavior should be implemented, I don't see much controversy putting the caret at the first line join, traversing through join points with TAB key, while END and ENTER would move the caret to eol, where next ENTER would create a newline. It should be also kept in mind that SHIFT+ENTER and CTRL+SHIFT+ENTER are still valid key bindings for creating a new line above and below the selected line.
>As far as preferences and default behaviors go, I do not think we need yet >another preference just to tell how to join lines... 100% agree. >IF the "new" join lines behavior should be implemented, I don't see much >controversy putting the caret at the first line join, Right, because that's how you like it ;-)
(In reply to comment #6) > >IF the "new" join lines behavior should be implemented, I don't see much > >controversy putting the caret at the first line join, > Right, because that's how you like it ;-) > But of course :) Anyhow, seeing how I am pushing my preference in this respect, maybe I am missing some of the use cases that absolutely *require* the caret to be positioned at the end of the joined line that can not be easily worked around when cursor is positioned at the line join point?
>some of the use cases that absolutely *require* the caret to be >positioned at the end of the joined line that can not be easily worked Please... What is the use case that absolutely requires to changes it?
Quite often, after I've joined lines, I need to edit the line at the immediate neighborhood of the joining point of these lines. An easy example - joining the long(ish) message that was split to multiple lines - first by joining the lines and then removing string concatenation. Or join the lines and add a variable between two strings. Or replacing the variable between strings with a MessageFormat placeholder. There are many things I would like to do after I've joined the lines that are made much more cumbersome to do when cursor is positioned at the end of the line. Also this would make quite common case of putting curly braces around simple if statement a much more convenient and concise operation if I could do that: /* the '|' symbol denotes cursor position */ if (blaah == true) doSomething(); 1. Join above 2 lines getting if (blaah == true) |doSomething(); 2. type opening curly brace: if (blaah == true) {|doSomething(); 3. type Enter: if (blaah == true) { |doSomething(); } There are definitely more cases, but these are two that I can immediately think of... The only use case I can come up with to support cursor at the EOL after join is to allow typing Enter to create a new (blank) line below the joined line. This is easily overcome just by typing shift+enter or typing END and then ENTER. Not all that many keystrokes, I would argue...
I often want to continue writing after having joined the lines. Please keep in mind that this command is not Java specific.
Oh, and I completely forgot my primary reason for wanting this - removing the space character generated by joining lines. It is truly annoying to join a method call that is split to multiple lines and then go over the joined line just to remove the spaces generated immediately after the opening parentheses and before argument separators (comma).
Roland, you may also comment on bug 179782 about your use cases. This would help to make the implementation smart enough to not depend on the caret placing for editing stuff you mentioned above.
(In reply to comment #10) > I often want to continue writing after having joined the lines. Please keep in > mind that this command is not Java specific. > And what is wrong with pressing END and then start typing? I must admit, I am mostly using Eclipse for programming in any of the supported languages (mostly Java, but also Python, JavaScript, XML/HTML, CSS, C++, etc.) I rarely use Eclipse for editing plain text, but I am positive, that combo of ctrl+shift+J -> End -> start typing is not all that much more onerous than current way.
(In reply to comment #12) > Roland, you may also comment on bug 179782 about your use cases. This would > help to make the implementation smart enough to not depend on the caret placing > for editing stuff you mentioned above. > I don't need it to be smarter. I need it flexible enough that it won't make things more difficult than they need to be. Even if there will be this smartness built into the joining lines, I still want that flexibility of revisiting all those smart joins and overriding the smartness where I need to...
*** Bug 333220 has been marked as a duplicate of this bug. ***
*** Bug 490857 has been marked as a duplicate of this bug. ***
