You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We suggest to use this issue as a storage for the most needed features and hottest bugs introduced in the latest version. We may fix the whole bunch of it within the next update or consider creating a separate issue for global and long-lasting issues.
Features
Enhance code completion
Right now it works pretty good, but is really hardcoded. We'd like to spend more time exploring what's going on inside the logic and how to make it cleaner and more efficient.
Enhance name validation
It has been turned off as the generic one does it work well, but we are still interested in exploring the benefits we could get from a custom one.
Return and enhance inspection (unused things)
We disabled it until it works more consistent. Requires refactoring and reconsideration.
Cover everything we can with tests
Right now we only have tests for parsing, but we can do better.
For example, we have these relations and an entity, playing their roles. The highlighting for the role itself works well, which is shown below. However, we cannot highlight the reference to the relation.
This is an additional issue because of the renaming feature: as we don't have a reference, we cannot rename it:
Before renaming:
After renaming:
It looks like a grammar-based inconvenience right now as for plays constraints leafs (the minimal entities of the trees without children) are scoped labels without more specification for the labels it consists of.
I haven't tried to make two references on one token, though, maybe there is a way to do it. I could also just use children of the entity for additional names, which wouldn't be that generic and clean, but it should work. But right now it just doesn't look that fast, so I wanted to highlight it.
Do not resolve ambiguity well.
For example, we have an incorrect define statement with two concepts with the same name and an entity which "owns" one of these concepts:
Even if we don't highlight an error (as we are not a compiler itself), we could at least make referencing based on types. For example, we can store the type of the original concept and also use a "preferable" type for references:
"owns" can reference only attributes;
"plays" can reference only roles;
"sub" can only reference something declared via "sub";
...
The text was updated successfully, but these errors were encountered:
Name validations are buggy now as they use the standard Java naming convention, which restricts such-names. To restore the name validator, we also need to restrict the main part of the special symbols and basically depend on our vocabulary. We also need to restrict using some of the keywords, but let the devs use RULE_unreserved tokens! So fixing it properly requires time.
We suggest to use this issue as a storage for the most needed features and hottest bugs introduced in the latest version. We may fix the whole bunch of it within the next update or consider creating a separate issue for global and long-lasting issues.
Features
Enhance code completion
Right now it works pretty good, but is really hardcoded. We'd like to spend more time exploring what's going on inside the logic and how to make it cleaner and more efficient.
Enhance name validation
It has been turned off as the generic one does it work well, but we are still interested in exploring the benefits we could get from a custom one.
Return and enhance inspection (unused things)
We disabled it until it works more consistent. Requires refactoring and reconsideration.
Cover everything we can with tests
Right now we only have tests for parsing, but we can do better.
Bugs
Cannot reference relations inside "plays" constraints.
For example, we have these relations and an entity, playing their roles. The highlighting for the role itself works well, which is shown below. However, we cannot highlight the reference to the relation.
This is an additional issue because of the renaming feature: as we don't have a reference, we cannot rename it:
Before renaming:
After renaming:
It looks like a grammar-based inconvenience right now as for plays constraints leafs (the minimal entities of the trees without children) are scoped labels without more specification for the labels it consists of.
I haven't tried to make two references on one token, though, maybe there is a way to do it. I could also just use children of the entity for additional names, which wouldn't be that generic and clean, but it should work. But right now it just doesn't look that fast, so I wanted to highlight it.
Do not resolve ambiguity well.
For example, we have an incorrect define statement with two concepts with the same name and an entity which "owns" one of these concepts:
Even if we don't highlight an error (as we are not a compiler itself), we could at least make referencing based on types. For example, we can store the type of the original concept and also use a "preferable" type for references:
The text was updated successfully, but these errors were encountered: