Bugzilla – Full Text Bug Listing
| Summary: | [formatter/api] Allow formatting based on model and parse tree (aka semantic formatting) | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Sven Efftinge <sven.efftinge> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | alex.tugarev, henrik.lindberg, moritz.eysholdt, vpiskarov |
| Version: | 1.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Sven Efftinge
It would be great to have the current EObject from the semantic model available in the formatter. This would allow to make formatting decisions based on the values of EAttributes, the amounts of values within an EList, etc... To pass the current AbstractNode to the formatter would be possible, too, but one shouldn't expect too much from it: - At first, when the formatter is called by the ParseTreeConstructor, some tokens might bot have an AbstractNode. The ParseTreeConstructor is called when XtextResource.save() is called. Some tokens don't have an AbstractNode when the semantic model has been modified *after* it has been created by the parser. E.g. by applying a Quickfix. Furthermore, *no* token will have an AbstractNode if the semantic model has not been created by the parser (e.g. an M2M transformation, EMyPackageFactory or read from XMI). - At second, the node model isn't needed to "access state of the parser", i.e. to see how the current stack of rule calls looks like. This information is implicitly available since it is possible to assign formatting instructions to rule calls and parser rules. However, these changes, would break API, so it's probably to late for Helios. This does work with the new formatter infrastructure. |