Discrepancies Between [code Node Behavior and Its Documentation #39
Replies: 3 comments 2 replies
-
The reason is that node Note: In older PML versions, only the Text Block Syntax syntax variation was supported. Sorry for the confusion.
This has been changed already. In the reference manual, only the node name is mentioned, the closing tag has been removed. And in the JSON file, field |
Beta Was this translation helpful? Give feedback.
-
I didn't know that. So, since in my example the contents are on the same line as the tags I was unknowingly using the Standard Text Syntax, hence the
Indeed you should. It seems like I'll have to rework the entire Sublime PML syntax in order to support these variations (hoping that it's even possible). The Variations Might Hinder Editor SyntaxesHonestly, the existence of these three different variations is going to make writing editor syntaxes much harder (possibly even more that lenient parsing does for attributes). This is a case that needs to be handled via backtracking, since you don't really know which of the three syntaxes is being used until you've parsed multiple lines. As far as I know, among modern editors with TextMate like syntax definitions, Sublime Text remains the only one that offers syntax backtracking and branching for handling ambiguous grammars — so I'm glad that ultimately I stuck to working on the ST syntax, instead of going for VSCode, since I wouldn't have liked to work on package that was destined to poorly cover the syntax. One might argue that most syntaxes could just go for the "official variation" mentioned in the docs, but this won't really work since users can still encounter the other variations in third party documents — and the Standard Text Syntax needs to apply escaping rules, and for the others it would be nice to have the block delimiters properly scoped and highlighted. Anyhow, I'll try to implement the other variations in Sublime PML after migrating to PML 3.0. |
Beta Was this translation helpful? Give feedback.
-
Yes, exactly.
True. They are convenient for end-users, but hard to implement in plugins with limited programming capabilities.
Yes. Without backtracking, it's probably not possible to correctly support the three syntax variations.
That might indeed be a very reasonable approach, especially in an early version of the plugin. |
Beta Was this translation helpful? Give feedback.
-
@pml-lang, I'm a bit confused by the
[code
node behaviour in PML 2.3.0...The following example compiles without error:
Except that the results are not as expected, i.e. it seems that the closing tag is no longer
node]
but just]
, since I get the following output:Both the current documentation and PML JSON Tags still mention the closing tag to be
code]
, but from the above examples is clear that only the bracket is taken into account.From the Sublime PML point of view, what should I do? Should I amend the syntax to match the real behaviour of PML? or is this a bug that will be fixed in the next update (PML 3)?
Beta Was this translation helpful? Give feedback.
All reactions