Community
Participate
Working Groups
If you have a comment like this: // this is a comment And you copy/paste the entire line to a new line (including leading indentation) you get the correct result: // this is a comment However, if you copy/paste the line *without* the leading indentation to a new line, you incorrectly get: // this is a comment
This is intended. The idea is that line comments with the '//' at offset 0 are probably commented out code and that the '//' should be preserved at the line offset. We might be able to find a better heuristic.
This is yet another case of Eclipse trying to be too smart and getting in the user's way instead of helping. Experimental behaviors like this bug and bug 42469 should always be accompanied by preferences to turn them off in the event that they don't measure up. As it is now, we are all stuck with these infuriating behaviors until these bugs percolate to the top of someone's bug list (assuming that ever happens).
*** Bug 102812 has been marked as a duplicate of this bug. ***
Is there any hope of this bug getting fixed in 3.2 M6 or final release ? While overall Eclipse shines, if there is one thing that is absolutely nasty in Eclipse - it is this bug. An irritated developer is bound to be less productive. Please consider fixing this (i.e remove the feature provided or provide preference control) Cheers and good will
Tom, we could be even smarter here i.e. indent the clipboard comment as is if there's not at least one indent between // and the first non-whitespace. Time permitting for 3.2
(In reply to comment #5) > indent the clipboard comment as is if > there's not at least one indent between // and the first non-whitespace. Agree that this will be correct in the 90% case.
By indent do we mean a tab ? What if tabs are converted to spaces on save ? (Which is what we do) Will this feature go away then for such cases ?
(In reply to comment #7) > By indent do we mean a tab ? What if tabs are converted to spaces on save ? > (Which is what we do) Will this feature go away then for such cases ? Indent means an indentation level, which is represented in code by one indentation unit. What this means in practice depends on your formatter settings (tab vs. spaces vs. mixed, indent size in spaces...). In short, this should work for all formatter settings, but the heuristic will fail when you commented out any code that is aligned at column 0, for example an entire class, because there is no formal difference between commented out code and a line comment.
May I suggest that we do not go down the path of "will work for 90% of the cases". It is going to cause grief to some user group who consistently use indents after the comment symbol. Can we not introduce a concept of "Paste Special" as in MS Word (and maybe other processors I am not aware of). This menu comes up with a Ctrl+RightClick and gives the user special pasting options as each menu action. These actions will be for the special pasting cases i.e. 10% of the pasting use case. Default behaviour of paste should cover 90% of the pasting use cases. We can also provide key board support for each special case action. This will also make way to fix 107493 neatly. Please consider this.
(In reply to comment #9) > May I suggest that we do not go down the path of "will work for 90% of the > cases". It is going to cause grief to some user group who consistently use > indents after the comment symbol. To disable for good, simply uncheck "Adjust indentation when pasting" on the Java > Editor > Typing preference page. To quickly toggle the behavior, use the "Edit > Smart Insert Mode (Ctrl+Shift+Insert" command from the main menu. When disabled, the indent will not be adjusted, but inserted as is. I think that this approach is a better option than adding a "Unformatted" or "Raw" option to each and every editing command.
Wouldn't disabling "Adjust indentation when pasting" impact all paste operations ? There is nothing wrong with "indentation when pasting" in general at the moment - except for this specific bug where comments are involved. The solution being offered will be an all or nothing proposition ? Please consider this.
Same is true about disabling "Smart Insert Mode" (not sure what set of functionality gets disabled) Yesterday (for one day) I tried the proposed solution each unformatted paste is Ctrl+shitf+insert - Ctrl+v - Ctrl+shift+insert ---- (1) Why not use the Shift operator to change the behaviour of the paste i.e. Ctrl+v will do a normal past and Ctrl+shift+v will do an unformatted paste i.e what ever (1) does ? Please consider this
>Yesterday (for one day) I tried the proposed solution each unformatted paste is >Ctrl+shitf+insert - Ctrl+v - Ctrl+shift+insert ---- (1) Note that if you copy/cut a comment that's on a line by it's own you have two other choices: - use the (copy+) move line command - select the entire line instead of taking the pain to just partially select it
(In reply to comment #13) > >Yesterday (for one day) I tried the proposed solution each unformatted paste is > >Ctrl+shitf+insert - Ctrl+v - Ctrl+shift+insert ---- (1) > Note that if you copy/cut a comment that's on a line by it's own you have two > other choices: > - use the (copy+) move line command Are you talking about Copy lines (Ctrl+Alt+Up/Down) and Move lines (Alt+Up/Down)? If so, they are only useful if you want to move/copy to adjacent lines. > - select the entire line instead of taking the pain to just partially select it It's actually slightly easier to hit Home, Shift+End to select the line minus leading whitespace (granted this is going to leave a blank line behind), as it is to hit Home, Home, Shift+Down to grab the entire line. Well, at least it *should* be, except bug 42469 currently prevents the first way from grabbing the comment characters (Argh!).
*** Bug 131136 has been marked as a duplicate of this bug. ***
*** Bug 145937 has been marked as a duplicate of this bug. ***
*** Bug 149868 has been marked as a duplicate of this bug. ***
*** Bug 150817 has been marked as a duplicate of this bug. ***
It seems like it would be rare for the user to moving around commented-out code. Even so, if I then auto-format what just got pasted, autoformat disagrees with what smart indent did. Use case: \t \tfoo = value; // Assign value User wants to change to: \t// Assign value \tfoo = value;
Targeting for M2.
One way to improve Eclipse to Eclipse copy is to add a separate DND transfer type for code comments (those that start at column 0).
Fixed in HEAD. Available in builds > N20061023-0010.
