One of the “gotchas” that trips MPS users sometimes is related to invalid property values.
For a given property cell MPS validates the input that you type in according to its rules. Some of the rules are built-in, such as not allowing alphabetical characters in integer properties, other rules can be defined by the language designer, such as not allowing spaces in identifiers.
What happens if you type in some text that does not form a valid value for a property but then navigate away from that
cell? MPS will turn the cell red and it will NOT write the offending value to the model. Here is what it looks like if
you try to name your class X@Y which is invalid according to Java naming rules:
However, there is nothing to indicate that the value was, in fact, NOT written. You may think that the X@Y was stored
in the model but in this case the model contains the old value, which happens to be X:
The same happens if you try to empty the class name. The property cell will read <no name> and be highlighted in red
but the previous value in the model will in fact remain.
This is exacerbated by the fact that these invalid values are stored somewhere. If you close the editor and open it again, or even if you tell MPS to invalidate caches and restart, the invalid value will still be ther, staring at you, and giving you the impression that it was safely stored in the model all the time.
Invalid property values are persisted, but not to the model. They are stored, out of all things, in a temporary file in the MPS config directory.
The issue was reported to JetBrains as MPS-33357 and it is even marked as fixed. However, the “fix” was adding an API to obtain a list of editors with error cells. This does not fix the core UI issue at all, of course, but it does give you means to check for the presence of such “uncommitted” error cells and notify the user when they attempt to generate or export the model.
There remains therefore no easy solution to this UI quirk. This is something to know and tell your users.