Fix PML Scoping Conventions #41
tajmone
started this conversation in
Syntax Elements
Replies: 1 comment
-
I totally agree. It's always better to 'first get the basics right'.
It's frustrating, indeed, if we have to 'try-and-error' because of the lack of standards and good technical documentation.
Sure. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@pml-lang, the reason why I've lately stopped updating the syntax with new elements is because I'm not quite happy with the current scoping conventions.
I'm realizing that some of ST native editing features are not working well with the current scopes:
Therefore, instead of growing the syntax I'd like to stop and rethink the current scoping conventions, and fix them in order to enhance syntax support of native editing features. If I keep adding elements, I will only make it harder in the future to fix the scope names, since any changes to the scopes entails fixing all the syntax tests, the color scheme definitions, etc., which is a lot of work.
Unfortunately, the ST documentation is extremely lacking when it comes to explaining which scopes play a role in default editing features. So, my only way to fix this is by looking into other syntax definitions, which scopes they use and how they play out with editing features, and try to adapt the current PML syntax to these examples.
Another big problem is that the PML syntax is unlike any other syntaxes (programming and markup), so it's not easy to determine how to break up scoping of node/tags. The presence of the square bracket definitely calls for using the proper bracket-scoping conventions, but the reason I had discarded this in the first place was because it would preclude using a node-oriented scope (it's either one or the other).
I've been aware of these problems since the beginning, but simply couldn't find any good compromise between the nature of the PML syntax and what appear to be ST requirement to support editing features.
I've started digging into various ST native syntaxes, their scopes and how they support editing features, and will post here my findings — it's a fairly long process, and some of the native syntaxes don't seem to be handling well these features I'm hoping to target either. Hopefully this research is going to be useful for other editors too, since they all tend to treat syntaxes alike, based on TextMate scoping conventions.
Now is the right time to fix these scoping issues, but if I keep piling up new scopes the syntax and its tests would grow too large to fix then.
Beta Was this translation helpful? Give feedback.
All reactions