Community
Participate
Working Groups
Using the sample grammar Model: greetings+=Greeting*; Greeting: 'Hello' name=ID '!'; and the model #start Hello Moritz ! Hello Sven ! #eof and using c.setNoSpace().around(f.getGreetingRule()); the formatted result is #startHello Moritz !Hello Sven ! #eof Note that if there is a comment at the end (ant not only WS), the formatter removes whitespaces before the comment. But it leaves trailing white spaces (same for f.getModelRule()). Enhancement request: Maybe it is possible to add configuration options ala c.noFileLeadingWhitespaces(), c.noFileTrailingWhitespaces(). The argument is that it may be hard to formulate a configuration "please line breaks before each rule x except if it is the first one in the file" or "please line breaks around rule y except if it is the last one in the file in which case there should be only a line break before the rule". (.bewteen(...) rules can be used to achieve that but there may be a combinatorial explosion on necessary configuration code). If there is a simple hook/possibility for eliminating leading and trailing white spaces (e.g. postprocessing the token stream in a very simple way) a corresponding note in the documentation (good work on the formatting part so far!!) would be very helpful.
I could think of introducing "artificial" grammar elements for the formatter to allow formatting instructions for the beginning/end of file. Example: c.setNoSpace().after(BEGIN_OF_FILE); c.setNoSpace().between(f.getFooAccess().getBarKeyword(), END_OF_FILE);
(In reply to comment #1) Do you mean something like Model: beginning=Beginning greetings+=Greeting* end=End; Beginning hidden(): {Beginning}; End hidden(): {End}; Greeting: 'Hello' name=ID '!'; ? It was a bit surprising to me that the dummy rules without any consumption were valid at all (and seemed to work, as objects of this type were created and had corresponding parser nodes). However, I could not find a set of rules eliminating trailing white spaces and new lines (same as in the original description). Further, would the introduction of these dummy rules work, if no meta model was generated but only an existing one is instantiated? Nonetheless, I think global "trim beginning", "trim end" options would be quite useful. With your proposed approach there might not be a combinatorial explosion, but in case a file can end in many different ways (due to alternatives, optional assignments), there would still be a lot of configuration code.
I have a test case which reads and writes an Xtext resource and compares the written file contents to the original source. On serialization the last EOL was dropped. It is expected that the serialized form matches exactly the original input file contents.
won't fix because it affects the old formatter infrastructure
