Community
Participate
Working Groups
Hi, I'm using Eclipse build F3 and in Java files I'm commenting out code using the CTRL+/ combination. That combination add "//" as the first two characters in the line. When I run the code auto formatter, it indent the comments too, but starting with "//". That means that you'll have "//" indented followed by a lot of spaces (or tabs) represented the old indent and the actual comment. Ideas? Maybe not indenting at all the left aligned comments (when "//" are the first two characters on a line). Thanks, Marcel
I'd love an option to -not- format comments where // is in column 1-2. Jalopy had something like this, I believe, and I got hooked on this feature (but switched back to Ecilpse's built-in formatter since Jalopy has become a commercial product). I know I can turn off comment formatting altogether, but it would be very useful to be able to do it in a controlled fashion like this.
*** Bug 61510 has been marked as a duplicate of this bug. ***
comment action should not call the formatter.
*** Bug 85096 has been marked as a duplicate of this bug. ***
It's not that comment is calling the code formatter. It's that a developer will comment out code, and then, perhaps days later, run the formatter to ease a large movement of code from one file to the next. We simply don't want the formatter to indent these lines again. A good rule is to either leave lines that start with "//" intact (in the formatter), or to indent the lines, but have the first non-whitespace character after the "//" to be immedately after the "//" (in the formatter). I prefer the first option.
Ownership changed.
*** Bug 110303 has been marked as a duplicate of this bug. ***
The new constant could be named: /** * <pre> * FORMATTER / Option to indent comments that start on the first column * - option id: "org.eclipse.jdt.core.formatter.indent_comments_on_first_column" * - possible values: { TRUE, FALSE } * - default: FALSE * </pre> * @see #TRUE * @see #FALSE * @since 3.2 */ public static final String FORMATTER_INDENT_COMMENTS_ON_FIRST_COLUMN = JavaCore.PLUGIN_ID + ".formatter.indent_comments_on_first_column"; //$NON-NLS-1$ I don't think it worth it to make one constant per comment type.
Of course, @since should say 3.3. I am not sure about the default value though. For compatibility with previous version it should be true, but people really seem to expect false.
+1
Regarding default: can't you make the headless formatter work as before (i.e. compatible) and use 'false' just in our Eclipse profile?
headless you mean the code formatter application ?
yup. not sure though whether they also access the Eclipse profile.
By default the code formatter application takes its options from the command line arguments. But if none are specified, then it takes the default from JavaCore options. So for the code formatter, this ends up being the Eclipse profile.
Created attachment 61138 [details] Proposed fix This fix preserves the default options (indenting comments on first column) for the Code formatter application if no options have been specified on the command line and set the Eclipse default to false (don't indent comments on first column).
I ran with this patch + UI patch (bug 177796) and I got the expected behavior. If somebody else wants to give it a try, this would be nice.
Daniel, I'd like to release it for M6, but this would require bug 177796 to also be released. Otherwise users might complain they cannot parameterized it from the UI.
Hi Olivier, I looked at both patches and how it feels when using them. I have two concerns: 1) the main driver behind this bug is that the Toggle Comment (and if we agree to expand this to all comments also Add/Remove Block Comment) action are preserving i.e. that the formatter doesn't shift/mangle the temporarily commented code. While the two patches fix the // problem they don't do so for the Add/Remove Block comment action. We should fix this or restrict the new preference to only act on single line comments. 2) putting the preference on the indentation section might be confusing - at least it was for me: I'd have expected this on the Comments page. In fact it is not about indenting the comment compared to other elements but whether their indentation is adjusted. Maybe the following might better catch it: [ ] Format comments starting at line beginning 3) the term 'first column' might be too technical for users: line beginning (or start) might be easier to grasp for them Let me know what you think. I can commit the UI code as soon as we're on the same page and the JDT Core code is in HEAD.
(In reply to comment #18) > 1) the main driver behind this bug is that the Toggle Comment (and if we agree > to expand this to all comments also Add/Remove Block Comment) action are > preserving i.e. that the formatter doesn't shift/mangle the temporarily > commented code. While the two patches fix the // problem they don't do so > for the Add/Remove Block comment action. We should fix this or restrict the > new preference to only act on single line comments. I tried the Add/Remove Block comment and it works fine. So if you tell me how you did it, I could try to see what needs to be fixed. > 2) putting the preference on the indentation section might be confusing - at > least it was for me: I'd have expected this on the Comments page. In fact > it is not about indenting the comment compared to other elements but whether > their indentation is adjusted. Maybe the following might better catch it: > [ ] Format comments starting at line beginning Format is misleading. This option is only about the indentation of the comment, but its formatting. So : [ ] Indent comments starting at line beginning And this is also why I clearly prefer it in the indentation page. > 3) the term 'first column' might be too technical for users: line beginning (or > start) might be easier to grasp for them We need to get an agreement on the option name asap. Its implementation can be proposed later. We could go for: FORMATTER_INDENT_COMMENTS_STARTING_AT_LINE_START but to be honest I prefer the actual name. It describes exactly where the comment is.
re item 1): have this: public class CFTEST { void foo() { System.out.println(); System.out.println(); System.out.println(); System.out.println(); } } 1. select the two system.out's in the middle 2. Source > Add Block Comment ==> public class CFTEST { void foo() { System.out.println(); /* System.out.println(); System.out.println(); */ System.out.println(); } } 3. Format with the new pref set to false (i.e. don't touch the commented lines: ==> public class CFTEST { void foo() { System.out.println(); /* System.out.println(); System.out.println(); */ System.out.println(); } } 4. Source > Remove Block Comment public class CFTEST { void foo() { System.out.println(); System.out.println(); System.out.println(); System.out.println(); } } Which is not what I had in the beginning and which I think is the only reason for the new preference (except of course for the // which now works fine).
Re item 2: yep, your right regarding the term "formattin". But it's also not indentation because what it really does is either ignore the comment or adjust it to the code. It has not the same meaning as the other indent prefs. >We need to get an agreement on the option name asap. The name of the constant in the code is fine. I'm only talking about what we expose to the user.
This is not related to the new option. It is a different bug. Note that if you enable the formatting of the block comment, it doesn't work either when you try to remove the block comment. So we should only not indent the comment, but also not format it at all. Then the option should be more. FORMATTER_IGNORE_COMMENTS_ON_FIRST_COLUMN and then I agree we should move it to the comment preference page.
So if we ignore, we should only modify the line break to match the one specified for the formatter and leave every else untouched.
>This is not related to the new option. Oops! you caught me - I wanted to sneak that in ;-) Now back to serious: since the new preference isn't solving this issue (which is OK) I think we might want to restrict the preference to single line comments - I couldn't find a use case where it would be useful for other comment types. >So we should only not indent the comment, but also not format it at all. Yep!
Or why don't we add an option that ignores the formatting of comment that starts of column 1 and then we could keep it for all type of comments? I think this is really what users are expecting.
Agreed, and it could also cover the scenario from comment 20.
(In reply to comment #25) > Or why don't we add an option that ignores the formatting of comment that > starts of column 1 and then we could keep it for all type of comments? > I think this is really what users are expecting. The problem with this approach is that it conflicts with headers and other comments that would not be indented anyway (javadoc comment of the type for example).
What you described in comment 20 is bug 49314. Note that the add/remove block comment action should also work after the comment has been formatted. Right now it doesn't. It leaves a '*' at the beginning of the second line.
As the new option describes an exception of the indentation rule, it's name should reflect that. What about: FORMATTER_NEVER_INDENT_COMMENTS_ON_FIRST_COLUMN I personally think splitting up into block and line comment would make sense. It would be more flexible and less risky. For Javadoc comment I don't see the benefit of not indenting. It seems to me that you always want the Javadoc comment to be aligned with the documented element. That would result in: FORMATTER_NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN FORMATTER_NEVER_INDENT_BLOCK_COMMENTS_ON_FIRST_COLUMN
Ok, that's fine. I'll split the new option into two constants. Like this we could workaround the issue from bug 49314. Ideally I'd like to fix it as well for 3.3. So I will propose a patch of the UI for bug 177796 with the two new constants moved to the comment preference page. Should be done today.
I prefer: FORMATTER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN FORMATTER_INDENT_BLOCK_COMMENTS_ON_FIRST_COLUMN where NEVER means option = FALSE. Ok for those names?
FORMATTER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN sounds like the comment on the first row would always be indented. To understand this option better, it's good to know that it is rather an exception to the indentation rules: 'Never indent any block comments on the first row' seems like the best explanation to me and 'false' would be the default value. As this option is new, it's also good to have 'false' as the default value.
(In reply to comment #32) > FORMATTER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN sounds like the comment on the > first row would always be indented. Not quite. It depends on the value. But I see your point. I don't really care what name we use. > To understand this option better, it's good to know that it is rather an > exception to the indentation rules: 'Never indent any block comments on the > first row' seems like the best explanation to me and 'false' would be the > default value. > As this option is new, it's also good to have 'false' as the default value. This would preserve the existing behavior (these comments are indented). Daniel wanted the default to be the opposite. So we need to agree on the default value. Since we are getting close to M6, I would release only the new constants without any implementation. The implementation will be supplied once M6 is done. This might allow me to get some time to fix bug 49314 at the same time. bug 177796 should then be fixed post M6.
The two constants have been added for 3.3M6, but with true as the default value for the Eclipse profile according to the Daniel's wishes. This makes sense if we consider the Add/Remove Block comment and Toggle comment actions. The actual behavior is far from being ideal. The implementation will be provided post 3.3M6.
What's the name for the preference now? Another idea that came to mind is to name the preference to what it actually does: treat comments that start at line beginning as disabled code. Hence the formatter would: 1. internally remove the comment start/end 2. format with the code 3. add the comment back
These are the names of the two constants: FORMATTER_NEVER_INDENT_BLOCK_COMMENTS_ON_FIRST_COLUMN FORMATTER_NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN Doing what you say might change the formatting of the commented code. This is not expected.
Created attachment 64665 [details] New patch
Released for 3.3M7. Regression tests added in org.eclipse.jdt.core.tests.formatter.FormatterRegressionTests.test658() org.eclipse.jdt.core.tests.formatter.FormatterRegressionTests.test659() org.eclipse.jdt.core.tests.formatter.FormatterRegressionTests.test660() org.eclipse.jdt.core.tests.formatter.FormatterRegressionTests.test661() org.eclipse.jdt.core.tests.formatter.FormatterRegressionTests.test662() org.eclipse.jdt.core.tests.formatter.FormatterRegressionTests.test663() and also updated some existing tests.
Verified for 3.3 M7 using build I20070418-1012.
