Blocking Text Styles Key-Shortcuts from Raw Blocks

[tajmone]

Currently, the keyboard shortcuts AltB → [b and AltI → [i are configured to take effect only if all cursors/selections are within a PML scope — i.e. not inside an [html node.

The logic behind this is to prevent users from accidentally spoiling a raw HTML blocks.

• [html — via -text.html
• [code — via -meta.embedded
• [input — node still unimplemented
• [output — node still unimplemented
• [table_data — node still unimplemented

NOTE — I could scope all those unprocessed nodes with a common meta scope (e.g. meta.unprocessed) which would make their maintenance easier. Currently I'm using the selector pattern:
text.pml -(text.html | meta.embedded)
where meta.embedded stands short for meta.embedded.block.listing, a shorthand pattern that will probably be shared by the other yet-to-implement nodes.

---

I'm not sure whether there are also other nodes that should prevent text styling via keys-shortcuts.

E.g. the [code node wraps a block of source code, but the documentation doesn't mention whether it might contain also some PML nodes or not — i.e. is it a "raw block", like the [html node, or are its contents processed by PMLC?

The point is that keyboard shortcuts for bold and italic should be configured to not work when the cursor is inside a node which does not support these nodes.

Without a BNF grammar of PML to consult, and lacking documentation regarding which nodes are allowed inside other nodes, we're left in the dark in respect to similar issues.

So, for the time being, let's keep the definitions as they are (excluding only [html), then in the future all of them will have to be revisited and checked out — once we have knowledge about PML behaviour in this respect.

Identical considerations apply to smart auto-completions — i.e. which nodes to exclude from suggestions in certain scopes.

[pml-lang]

the keyboard shortcuts AltB → [b and AltI → [i are configured to take effect only if all cursors/selections are within a PML scope

Yes, that's the correct way to do it.

I'm not sure whether there are also other nodes that should prevent text styling via keys-shortcuts.

The same behavior should be applied to all nodes that contain raw text. At the moment, these nodes are:
html, code, input, output, table_data

In the future some of these nodes might have an attribute that enables PML markup code within the raw text to be processed (for example to show some parts of source code in bold). However, by default PML markup is not processed in raw text blocks.

I think we should add a boolean field like is_raw_text_block in the JSON data exported by the pmlc command export_tags, so that the information will be automatically available in the future. If you think that this is useful I will send you a new JSON file.

[tajmone]

The same behavior should be applied to all nodes that contain raw text. At the moment, these nodes are:
html, code, input, output, table_data

If my understanding is correct, since these are raw blocks escaping rules should not apply to them either. Is it so?

If yes, I should disable matching escapes inside those nodes.

In the future some of these nodes might have an attribute that enables PML markup code within the raw text to be processed (for example to show some parts of source code in bold). However, by default PML markup is not processed in raw text blocks.

Asciidoctor does that too, via the subs option which allows to control which type of parsing should be enables or disabled in a block (e.g. macros, attributes, replacements, etc.).

But beware that this is also one of those double-edged features that is going to limit the editors which can fully support the syntax (there is no full support for the AsciiDoc syntax, it would require a Lang Server, but since there are various AsciiDoc implementations with small differences, chances are it will never be supported to its full potential).

I think we should add a boolean field like is_raw_text_block in the JSON data exported by the pmlc command export_tags, so that the information will be automatically available in the future. If you think that this is useful I will send you a new JSON file.

That should be useful, not only for quick consultation but also for automated generation of docs, templates, syntaxes, etc., which would lookup this info and act accordingly.

I also wanted to ask you, you should also export the closing tag, otherwise it won't be possible to auto-generate simple highlighters via Mustache, because not all nodes end with ] (e.g. hmtl], code], etc.). For full automation to be possible, that info is also required.

[pml-lang]

If my understanding is correct, since these are raw blocks escaping rules should not apply to them either. Is it so?

Yes, correct.

That should be useful

Ok, I will add field is_raw_text_block in the JSON export.

also export the closing tag

The closing tag depends on is_raw_text_block. All raw text blocks are closed by <tag_name>], all others are closed by ]. Do you prefer to have an additional field (e.g. "closing_tag" = "html]", or is field is_raw_text_block enough?

[tajmone]

The closing tag depends on is_raw_text_block. All raw text blocks are closed by <tag_name>], all others are closed by ]. Do you prefer to have an additional field (e.g. "closing_tag" = "html]", or is field is_raw_text_block enough?

Most template engines are "dumb" and logic-less, so it would be a safer bet to provide both the opening and closing tag for each node, possibly as a JSON compound object that is easy to traverse with a templating engine using a FOR EACH construct to iterate through all the nodes, and extrapolate the opening and closing tag at each iteration. Since the engine is dumb, these fields must be available at each iteration, with consistent names.

I can't really speak for all template engines, but Mustache would be a good candidate for this sort of operation. Although Mustache does support function calls that would allow to peak around the JSON file (e.g. check whether the node has is_raw_text_block) these functions would not be portable but specific to the Mustache implementation (e.g. Ruby, Lua, etc.), whereas it would be preferable to provide language agnostic templates.

[pml-lang]

it would be a safer bet to provide both the opening and closing tag for each node

Ok, will be done.

[pml-lang]

Here is the new JSON file created with the converter's export_tags command:

pml_tags.zip

The following fields have been added for each node:

• is_raw_text_block (e.g. false for node ch, true for node html)
• opening_tag (e.g. [ch for node ch, [html for node html)
• closing_tag (e.g. ] for node ch, html] for node html)

The new version of the converter is not yet available on pml-lang.dev.

[tajmone]

Here is the new JSON file created with the converter's export_tags command:

This looks great.

When the next release is out, I'll put it immediately to the test in Sublime PML's Wiki, where I'll use a script and Mustache to auto-generate a Wiki page with a reference table of all the supported nodes and their opening and closing tags; so I'll have a chance to actually play around with Mustache and see what else I can automate on the Wiki.

Now that we'll have also the closing tags, it should also be possible to auto-generate a simple editor syntax (e.g. for Vim). I'll try that on the Playground repo and see where it gets us — we might even consider a first simple VSCode syntax, autogenerated via Mustache templates.

The new version of the converter is not yet available on pml-lang.dev.

Any ETA? (just curiosity, not putting pressure)

[pml-lang]

test in Sublime PML's Wiki
auto-generate a simple editor syntax (e.g. for Vim)
might even consider a first simple VSCode syntax

Awesome!

Any ETA?

Next week I'll update everything. But the new parser will not yet be included.

[pml-lang]

FYI: Version 1.5.0. is now public. See CHANGELOG.txt for new features.

I am currently working on the new parser. Should be ready in a few weeks (including some new features discussed in the past).

[tajmone]

I'll download it straight away and update the package. In the past week I didn't manage to find as much free time as I wanted, due to some practical problems, but hopefully this week I'll catch up.

I am currently working on the new parser. Should be ready in a few weeks

Looking forward to it, with great expectations!

[tajmone]

@pml-lang, I've just updated the Sublime PML package and implemented the new [sub, [sup and [strike nodes (these were easy enough, just like bold and italics).