Sublime PML

[tajmone]

Hi Christian,

I wanted to inform you that I've now made public my repository of the PML package for Sublime Text:

https://github.com/tajmone/Sublime-PML

Although still in early Alpha stage, end users can already install it (via Git only, currently) and benefit from it, even if it's not complete.

Some PML nodes are already implemented, all others are simply captured as "generic" nodes. Attributes are not yet implemented, since I'm planning to target them on a per-node basis.

The choice of implementing the PML syntax with "nodes awareness" (i.e. granular scoping of syntax elements) is going to take longer, but it will provide many added benefits by allowing smarter auto-completion, based on the editing context — e.g. only attributes pertinent to the current node being editing will be suggested for auto-completion, and similarly only context-appropriate snippets will be triggerable.

Unfortunately, [Sublime Text] is a commercial editor (although it comes at a reasonable price).
It might be a good idea to also consider creating a PML package/plug-in for open source editors, e.g. VSCode, Atom, Notepad++, Vim, etc.

I'll look into VSCode, which I do use now and then, and for which I've already read the package developer's documentation — it's actually easier to create a PML syntax for VSCode, but it won't be as powerful as Sublime Text, not unless one creates a PML Language Server.

In any case, I believe it's important to provide a PML plug-in for a free and open source editor, in order to promote its usage.

[tajmone]

BTW, if you'd like me to transfer ownership of the Sublime-PML repository to the @pml-lang or the @practical-markup-language organization, I'll be happy to do it. After all, it makes more sense to keep PML related assets under its umbrella orgs, relinquishing control to you. But this can also be done later on, at any point, so we might as well wait that the package reaches a good Beta stage (it might take some time).

What's the difference between the @pml-lang and the @practical-markup-language organizations anyway? I find it a bit confusing that there are two different PML orgs, hosting different PML related projects. Has it go to do with separating end users' assets from developers' projects?

[pml-lang]

transfer ownership

That very kind of you. Thanks.

this can also be done later on

I agree.

difference between the @pml-lang and the @practical-markup-language

I will move the PML source code of the user manual to @pml-lang and remove @practical-markup-language. Everything related to PML should indeed be grouped together in a single project: @pml-lang.

[tajmone]

Repository Social Card

I've added to the Sublime-PML repository a social media card, here is how it looks on Twitter's Card validator:

I hope you don't mind me having used the PML logo here.

[pml-lang]

I like the social media card. Looks good.

don't mind me having used the PML logo here.

No problem at all.

[pml-lang]

made public my repository of the PML package for Sublime Text

Awesome! Thank you so much.

People love syntax highlighting, code completion, and other editor goodies. Good editor support surely makes PML more attractive.

I would like to share some thoughts on this important subject. I have no real experience with creating editor plugins, so please take the following with a grain of salt, and let me know if anything is unclear or wrong.

Basic principle:

• It's hard to create plugins (syntax highlighting, code completion, etc) that work perfectly well in all cases.
• It's often easy to create plugins that work reasonably well in many cases.

It's hard to create 'perfect' plugins because some functionality must be context-aware (or, as you call it, "nodes awareness"). For example [ch should be highlighted, but not if it is contained in raw text (e.g. a source code example, embedded HTML code, etc.). On the other hand, the risk of having [ch in raw text is not high, and users will (hopefully) understand a glitch here and there, if they know they are using a 'work in progress'.

So maybe we should start with not-perfect-but-pretty-useful plugins for popular editors (VSCode, SublimeText, etc.).

Some syntax highlight features that should not be hard to implement:

• Display [doc, [document, [ch, etc. in color T (tag), because it's a valid tag.

• Display [foo etc. in color E (error), because it's an invalid tag.

• Display ], not preceded by \, in color T (tag), because it's a tag end.

• Display the regex title\w*= in color A (attribute), because it's possibly a valid attribute (depending on the tag)

• Display the regex foo\w*= etc. in color E (error), because it's an invalid attribute

• Display comments (e.g. [- comment -]) in color C (comment). Note that PML comments can be nested. Don't know how easy/difficult this is to implement in a plugin. As a good start, it should at least work for non-nested comments.

• Display escape sequences (\[, \], \\, and \u1234) in color ES (escape sequence).

In 2018 I created a 'quick-and-dirty-PML-test-plugin' for VSCode to see how the above features could be implemented. I found it really easy to do that in VSCode (without using a language server). If you're interested I can send you the code.

Another point to consider: As PML is still in its early days, the syntax might change in the future (although this must certainly be avoided if possible). Hence editor plugins might need to be adapted too. It might make sense to use the pXML syntax for attributes (described in https://www.codeproject.com/Articles/5296768/Suggestion-For-a-Better-XML-HTML-Syntax), but I'm not yet sure about that.

Another idea: The PML-to-HTML-Converter knows all the valid tags and attributes per tag. Therefore it might make sense to let the converter auto-generate (and maybe even auto-install) the plugin code (or at least parts of the plugin code). If a tag/attribute is added/removed/modified later, the converter could just re-generate new plugin code. Moreover, plugin code would always be in sync with the PML version installed on the user's PC. The plugin code can still be published in a Github repository, so that users can suggest improvements via PRs. The modifications can then be integrated back into the converter, to produce better plugins. At the bare minimum the converter should be able to output a list of tags and related attributes, to help creators of editor plugins and other tools.

Side note: I have used a similar approach with PML's reference manual which is auto-generated. The converter writes the PML code for the reference manual into a .pml file, and then converts it into a .html file. You can see the source code for this process here:
https://github.com/pml-lang/converter/blob/main/work/src/PPL/dev/pml/converter/utilities/reference_manual/se_PML_reference_manual.ppl

What are your thoughts on this?

[tajmone]

Add context awareness. E.g. title = is not highlighted if it appears in a block like [code or [html, or in a comment.

This is already partly implemented, i.e. everything inside [html is passed to ST3's HTML syntax (native), so if it's highlighted it's because the HTML syntax does, but it would be a different scope altogether.

As for [code, it will automatically treat all text as verbatim, once implemented.

And title = is displayed as an error if it's used with an [i tag.

This should be achievable, but only after all nodes are implemented and we have a very robust syntax test suite. See tajmone/Sublime-PML#10 on my idea for this, and also about the tech perplexities that might hinder it.

[pml-lang]

Ok. Good!

[pml-lang]

If I add you to Sublime PML as a collaborator, you should be able to move Discussion threads from this repository to Sublime PML.

Thanks for adding me as a collaborator to 'Sublime PML'.
However, Github lets me only move discussions to repositories I own. Being a collaboration is not enough.
When I click on 'Tansfer discussion' Github says:
"Choose another repository you own to move this discussion to:"
It doesn't accept your repo as destination.
So we'll keep the discussion here. No problem.

[tajmone]

Sorry, I though it would be enough. Anyway, it's good to have you on board as a collaborator. You'll be able to handle Issues, labels, and the Dashboard, as well as review PRs, etc., so it's useful even though it doesn't solve this specific problem.

[pml-lang]

Nice! Thank you, Tristano.