Community
Participate
Working Groups
If comments are right behind a place where the level of indentation is increased/decreased, the comments have the wrong level of indentation. Example: hugo1 { // comment1 blablabla } This is because formatting instructions are typically matched at the transition from one token to the next, i.e. the next token has to be matched to actually find the instruction. In the example above the change in indentation will be noticed by the formatter when it reaches "blablabla". When formatting comments, the formatter would need to do a lookahead to the next semantic token. This would also improve the possibilities to merge formatting instructions that are triggered by a comment with the instructions related to the surrounding semantic tokens.
*** Bug 280066 has been marked as a duplicate of this bug. ***
In MWE2 I observed that ML_COMMENTs following a SL_COMMENT have no indentation at all.
*** Bug 406152 has been marked as a duplicate of this bug. ***
We also observed this problem (on Windows, it's not a Mac specific problem apparently). Examples: Example 1: FUNCTION_BLOCK FUB_LEDCylon /* * The LEDs are shifted back and forth. */ VAR_INPUT Trigger : BOOL; END_VAR END_FUNCTION_BLOCK Example 2: PROGRAM RaspberryPiPiface VAR /* 1st digital input of the PiFace */ DInput1 : BOOL; /* 2nd digital input of the PiFace */ DInput2 : BOOL; END_VAR END_PROGRAM
We had the same problem when providing formatting-support for an XPath-based grammar. Our workaround looks as follows: We subclassed Line. We subclassed FormattingConfigBasedStream to override createLine(List<LineEntry> initialEntries, int leftover) to return subclass of line and override createLineEntry(7 parameters. The latter method looks like this: @Override public LineEntry createLineEntry(EObject grammarElement, String value, boolean isHidden, Set<ElementLocator> beforeLocators, String leadingWS, int indent, ParserRule hiddenTokenDefition) { afterComment = inComment; inComment = isComment(grammarElement); lastIndent = indent; return super.createLineEntry(grammarElement, value, isHidden, beforeLocators, leadingWS, indent, hiddenTokenDefition); } In the subclass of "Line" we access the members "afterComment" and "inComment" in "add(..)": @Override public Line add(LineEntry lineEntry) throws IOException { if (afterComment) { // take the indention of the entry added last and correct this line indent = getIndentation(lastIndent); } afterComment = inComment; return super.add(lineEntry); } This seems to work well except if multi-line comment follows multi-line comment. Might not be a general solution though.
Hey. The proposed workaround does not work for us. I implemented it quite similar, but comments in the first line after a { are not indented. Actually the bad thing is, that indentation of the first comment line is /removed/ on format. thus it looks like this: persistent XX { /** * asd */ data-category XX; that's not cool :( any other ideas on how to fix that or work around the issue?
The workaround sounds complicated... Given that this is a standard situation which lets the formatter fail: do you think that you can provide a fix?
I would also be very interested in getting this issue fixed. For those users of our DSL that invoke the formatter this will most probably be the first issue they will discover...
I already also voted on this a while ago, and actually this bug is preventing us from enabling a "format on save" feature company wide to get uniform formats in our (multiple hundreds) DSL files :(
We're currently building a completely new formatting infrastructure for Xtext. An alpha version has already been release with Xtext 2.8.0: http://www.eclipse.org/Xtext/releasenotes.html#new-formatter-provisional The new infrastructure fixes this and several other problems with the formatter. We'd rather get the new infrastructure great and API-stable then invest time into the hard-to-maintain code base of the old formatter.
The new formatter API was released in the meantime, and the old API is now deprecated.
