Bugzilla – Full Text Bug Listing
| Summary: | Xtext-based editors should also work on files with non-matching file extension | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Moritz Eysholdt <moritz.eysholdt> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | anton, error-reports-inbox, ldubox-coding101, sebastian.zarnekow, sven.efftinge |
| Version: | 2.8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | v2.7.3 | ||
|
Description
Moritz Eysholdt
This is a regression. There was also some guy on the newsgroup who stumbled upon it. In my case it's a bug reported for Xpect: https://github.com/meysholdt/Xpect/issues/153 (Hi, I'm the Xpect ticket logger...) Maybe this functionality targets some different use-cases to ours, but personally I'd rather the development environment did not activate XText-based editors for DSLs under development. (*.dmodel files.) I would expect them to be enabled in the runtime-eclipse environment only. Certainly in our current state of development (e.g. with complex, partially-implemented and bug-ridden Scope Providers) it sounds like a recipe for fragility. (I'm also undecided whether I'd want DSL-editing functionality for *.dmodel.xt files in Xpect - I'm leaning towards no, but then again maybe it will prove useful later...) Anyway, I guess the main topic here is the regression/crashes. (In reply to Luke Usherwood from comment #3) > Maybe this functionality targets some different use-cases to ours, but > personally I'd rather the development environment did not activate > XText-based editors for DSLs under development. (*.dmodel files.) I would > expect them to be enabled in the runtime-eclipse environment only. Not sure I understand, but of course DSLs under development, i.e. in the workspace are not being activated automagically. You need to install them or start a runtime-eclipse environment if you want to use that language tooling. (In reply to Luke Usherwood from comment #3) > Maybe this functionality targets some different use-cases to ours, but > personally I'd rather the development environment did not activate > XText-based editors for DSLs under development. (*.dmodel files.) I would > expect them to be enabled in the runtime-eclipse environment only. Your expectation holds true... Xtext only enables editors when the language has been installed into the running eclipse. And Xtext only enables editors for files with a file extension the language has been registered for. This bugzilla ticket complains that if you open an editor from an installed language via "Open With" -> "Other..." -> (pick editor from dialog) on a file with a non-matching file externs, the NPE is thrown. > Certainly in our current state of development (e.g. with complex, > partially-implemented and bug-ridden Scope Providers) it sounds like a > recipe for fragility. Luckily its not fragile because when your language isn't installed your code won't be executed. When Xpect offers an editor on your files (e.g. *.dmodel.xt), and the model language is not installed, then the Xpect editor will only support the XPECT-syntax. Xpect offers an editor on all text files that seem to contain XPECT-statements. > (I'm also undecided whether I'd want DSL-editing functionality for > *.dmodel.xt files in Xpect - I'm leaning towards no, but then again maybe it > will prove useful later...) It's only the DSL-editing functionality for the Xpect-syntax. To get the editor that has DSL-editing functionality for XPECT-syntax and dmodel-syntax, the dmodel-language needs to be installed. Right, so the fact that I happened to trigger this on a file called "*.dmodel" was not relevant. Thanks for the clarifications. pushed fix to https://git.eclipse.org/r/#/c/34629/ we decided offline for a different solution strategy than initially proposed. From the commit message: The DirtyStateEditorSupport should only announce resources as dirty state, if the resource's language is the same as the lanugage registered for the resource's URI. E.g. If you open an "Arithmetics Editor" on "foo.xtext", the edtor sould not contribute dirty state because its exportet IResourceDescription can be significalty different (based on the arithmetics language) compared to what clients expect (IResourceDescription based on the Xtext language). Great stuff, thanks for the quick fix! This is already fixed. Also available for 2.7.3. Moritz, please reopen if there are any open ends. *** Bug 446693 has been marked as a duplicate of this bug. *** |