Community
Participate
Working Groups
Take two lines of Java code: a = 1; b = 2; 1) Selecting both lines and commenting them (ctrl+/) will comment them out as: // a = 1; // b = 2; 2) Selecting both lines again and applying the formatter (ctrl+shift+F): // a = 1; // b = 2; 2) Taking the original commented lines, and applying clean up (or the equivalent save action) to format code: // a = 1; // b = 2; 3) Taking the original commented lines, and applying clean up to correct indentation, produces: // a = 1; // b = 2; 2) Taking the original commented lines, and applying clean up to correct indentation AND format code: // a = 1; // b = 2; At least, commenting lines (ctrl+/) should produce the same indentation as defined in the code clean up or the code style formatting rules from the preferences or the project settings.
There's a comment formatter option that preserves line (and block comments) that start in first column. Unfortunately this seems broken in 3.4.
See bug 20793 which asked to introduce those preferences so that format works nicely together with Toggle Comment.
(In reply to comment #1) > There's a comment formatter option that preserves line (and block comments) > that start in first column. Unfortunately this seems broken in 3.4. > This option works in 3.4 as it did in 3.3. If it is activated while formatting! // a = 1; // b = 2; you get the same output using 3.3 or 3.4: // a = 1; // b = 2; So, IMO, this bug should be put back to UI... Dani, what's your mind?
Yes, my memory lost me: while I was pushing to get a 'do not format if comment starts at line start' a 'do not indent if comment starts at line start' was added.
To fix this bug we finally need the option to exclude end-of-line comments that start at the beginning of a line.
(In reply to comment #5) > To fix this bug we finally need the option to exclude end-of-line comments that > start at the beginning of a line. > I guess you meant an option while correcting indentation, right?
>I guess you meant an option while correcting indentation, right? No, we need an formatter option to tell the formatter to keep his hands off those comments. That's what I wanted to push for when the other option got added but it fell through the cracks.
Created attachment 160324 [details] Proposed patch + doc This patch adds two new formatter preferences to disable/enable the formatting of line/block comments which start on first column. Note important fact that disabling these comments also disable their indentation, otherwise the formatter could no longer produce stable outputs...
Created attachment 160495 [details] New proposed patch + doc This patch removes the option for the block comments as that does not present a real interest. Typically block comments are most of the time not on the first column when using the 'Add Block Comment'... It also renames the option for a better name, making clearer that this new option is a sub-option of the existing 'Format line comments' option.
Created attachment 160496 [details] New proposed patch + doc Improve the doc in build notes...
(In reply to comment #10) > Created an attachment (id=160496) [details] > New proposed patch + doc > Released for 3.6M6 in HEAD stream.
I think the dependencies between the line comment formatting options are not right. FORMATTER_COMMENT_FORMAT_LINE_COMMENT_STARTING_ON_FIRST_COLUMN should be a sub-option of FORMATTER_COMMENT_FORMAT_LINE_COMMENT, i.e. when LINE_COMMENT is false, toggling LINE_COMMENT_STARTING_ON_FIRST_COLUMN should not have any effects. In that situation, LINE_COMMENT_STARTING_ON_FIRST_COLUMN currently doesn't enable formatting of line comments on column 0, but it enables/disables the option FORMATTER_NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN when the latter is false. FORMATTER_NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN should stay independent of other options (like in 3.5), since this option is only concerned with indentation of the whole comment, and not with the formatting *inside* a comment. The last attachment in bug 304052 implements the UI for this. The patch there has the enablement dependency for the new option disabled, so you can use it for testing the formatter fix.
(In reply to comment #12) > I think the dependencies between the line comment formatting options are not > right. > > FORMATTER_COMMENT_FORMAT_LINE_COMMENT_STARTING_ON_FIRST_COLUMN should be a > sub-option of FORMATTER_COMMENT_FORMAT_LINE_COMMENT, i.e. when LINE_COMMENT is > false, toggling LINE_COMMENT_STARTING_ON_FIRST_COLUMN should not have any > effects. > I agree, this is currently not working properly, I'll fix this... > In that situation, LINE_COMMENT_STARTING_ON_FIRST_COLUMN currently doesn't > enable formatting of line comments on column 0, but it enables/disables the > option FORMATTER_NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN when the latter is > false. > Not sure to have understood this chapter... > FORMATTER_NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN should stay independent > of other options (like in 3.5), since this option is only concerned with > indentation of the whole comment, and not with the formatting *inside* a > comment. > It's no longer possible with this new option. There's a stability issue when the following conjunction of options values is set: - LINE_COMMENT: true - NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN: false - LINE_COMMENT_STARTING_ON_FIRST_COLUMN: false Then, the following snippet: class X { // first column comment } is formatted as: class X { // first column comment } and is re-formatted as class X { // first column comment } The first formatting does not format the comment contents as the option says to not format line comment at first column, but as the option to never indent line comment on first column is false, the comment is indented. The second formatting does format the comment contents because the line comment has been indented and is no longer at column 0... Hence, with this options configuration, we introduce an instability while formatting code which has line comment at first column and of course, this is not acceptable... The possible solutions are: 1) not indent the comment and let it unformatted at first column 2) indent the comment and format it during the first formatting My personal feeling is, of course, for the first solution (which is currently implemented in HEAD) because the second one would make me feel that the comment was formatted although I set the preference not do so... but I may be wrong. > > The last attachment in bug 304052 implements the UI for this. The patch there > has the enablement dependency for the new option disabled, so you can use it > for testing the formatter fix. I've played a little bit with your patch and the first dependency (i.e. LINE_COMMENT master of LINE_COMMENT_STARTING_ON_FIRST_COLUMN) does not seem to work properly. Am I right?
Created attachment 160758 [details] Patch to fix the option dependency inconsistency (In reply to comment #13) > (In reply to comment #12) > > I think the dependencies between the line comment formatting options are not > > right. > > > > FORMATTER_COMMENT_FORMAT_LINE_COMMENT_STARTING_ON_FIRST_COLUMN should be a > > sub-option of FORMATTER_COMMENT_FORMAT_LINE_COMMENT, i.e. when LINE_COMMENT > > is false, toggling LINE_COMMENT_STARTING_ON_FIRST_COLUMN should not have any > > effects. > > > I agree, this is currently not working properly, I'll fix this... This patch fixes this inconsistency.
(In reply to comment #14) > Created an attachment (id=160758) [details] > Patch to fix the option dependency inconsistency > Released in HEAD. I let the bug reopened until an agreement is found on the dependency between - NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN and LINE_COMMENT_STARTING_ON_FIRST_COLUMN options...
HEAD behaves fine now, but the Javadoc of FORMATTER_COMMENT_FORMAT_LINE_COMMENT_STARTING_ON_FIRST_COLUMN should tell that this option is ignored if FORMATTER_COMMENT_FORMAT_LINE_COMMENT is disabled. (In reply to comment #13) > Not sure to have understood this chapter... Never mind, this has been implicitly fixed by your last patch. > > FORMATTER_NEVER_INDENT_LINE_COMMENTS_ON_FIRST_COLUMN should stay independent > > of other options (like in 3.5) > [..] Thanks for the explanation. I agree now that we should just leave this as it is. > > The last attachment in bug 304052 implements the UI for this. The patch there > > has the enablement dependency for the new option disabled, so you can use it > > for testing the formatter fix. > > I've played a little bit with your patch and the first dependency (i.e. > LINE_COMMENT master of LINE_COMMENT_STARTING_ON_FIRST_COLUMN) does not seem to > work properly. Am I right? Yes, that's what I meant with "dependency for the new option disabled". I'll release this with a working dependency.
(In reply to comment #16) > HEAD behaves fine now, but the Javadoc of > FORMATTER_COMMENT_FORMAT_LINE_COMMENT_STARTING_ON_FIRST_COLUMN should tell > that this option is ignored if FORMATTER_COMMENT_FORMAT_LINE_COMMENT is > disabled. > Done. > Thanks for the explanation. I agree now that we should just leave this as it > is. > ok, great > Yes, that's what I meant with "dependency for the new option disabled". I'll > release this with a working dependency. > I agree that HEAD behavior is now OK, thanks :-) As the first point is now fixed and we agreed on the second one, I set back this bug as fixed...
Verified for 3.6M6 using build I20100305-1011
