Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320074

Summary:	[Formatter] eliminating trailing white spaces (file)
Product:	[Modeling] TMF	Reporter:	Alexander Nittka <alex>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	carl.wannheden, karsten.thoms, moritz.eysholdt
Version:	1.0.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Alexander Nittka

2010-07-16 03:06:17 EDT

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.

Comment 1 Moritz Eysholdt

2010-08-23 05:50:15 EDT

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);

Comment 2 Alexander Nittka

2010-08-25 10:18:56 EDT

(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.

Comment 3 Karsten Thoms

2010-08-30 15:32:42 EDT

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.

Comment 4 Moritz Eysholdt

2016-07-21 04:28:31 EDT

won't fix because it affects the old formatter infrastructure