Replies: 4 comments 12 replies
-
All Nodes Scopes RefactoredOK, I've managed to enforce the new scope naming convention on all nodes currently supported by Sublime PML:
A quick test comparing how a PML doc is rendered using the various ST native colour schemes reveals a much better syntax highlighting experience out of the box — every node is highlighted consistently now. You should notice these highlighting changes too (i.e. if the package is being self-updated correctly, via Git, as it should). I can now start working on the default colour scheme to include in the package, and the new scopes names make it very easy to tweak the style of entire node bu types (i.e. via For "raw-text" block nodes (see #24) I've also added an extra |
Beta Was this translation helpful? Give feedback.
-
I'm really not an expert when it comes to color schemes. Anyway, here are my subjective thoughts. In a nutshell, I agree with everything said in your comment. No doubt - Sublime PML will be great.
Great!
Good.
Yes, that's useful.
Very nice to have.
Sounds good.
I agree. Too much color disturbs.
Personally I don't like schemes with too much different colors. I find it more disturbing than useful.
I would expect to have different colors for:
Maybe nice to have: special colors for typed attribute values (date, time, regex, file path, etc.)
Agree! One more point: |
Beta Was this translation helpful? Give feedback.
-
Hi Tristano (@tajmone), I initially followed the installation instructions as given in the main README. I then removed the "PML" folder created by the and I presume that there should be another command for Sublime Text to "forget" about the files installed via the initial "git"? In any case, (when the package was working correctly), the bold and italic are displaying as expected and I like how the "code" and "html" blocks are highlighted! I find that the PML-Dark colour scheme is quite suitable. Again, like Christian, I don't like too many colours as it confuses the intent behind the code. A good colour scheme should draw the eye to the important elements without being a distraction. For now, I will go back and install the package via the Kind Regards, |
Beta Was this translation helpful? Give feedback.
-
Considering that:
... and:
... it makes total sense to prioritize a PML plugin for VSCode. Considering the frustrations you encounter with ST's package control, I can fully understand why you would
And:
Exactly! You have a lot of experience with developing editor plugins. If you start working on a PML plugin for VSCode, you will quickly be able to evaluate the differences, and take a final decision. |
Beta Was this translation helpful? Give feedback.
-
Hi @pml-lang and @celtic-coder, I wanted to share with you some thoughts on the PML syntax scoping rules and colour scheme.
I've started working on a default colour scheme (in a local branch); because PML is markup syntax it's better to provide a couple of custom schemes with the package, in order to provide the best end user editing experience — most markup packages do this, e.g. Markdown and Asciidoc.
So far, I've tried to stick to ST's guidelines in scope naming conventions, but I'm not quite happy with the results: too many scopes to deal with, and none of them truly representative of the nature of the PML elements they refer to.
I've been looking at how the Markdown and AsciiDoc package use scoping, but they seem to deviate from the suggested guidelines and adopt their own conventions in many cases, in order to achieve best results.
This is partly inevitable, since scope naming is really something which is till in-the-making. It started with the TextMate editor, and was adopted by many other editors in the course of time, and guidelines are really somewhat of a compromise between what the native features of an editor expects, and the gathered experience of best practices that come from real case usage packages/extensions in the wild.
At it's core, there's always the desire to ensure that generic colour scheme will represent faithfully the highlighted document, but also that native and third party plugins features will work as expected, thanks to proper scoping.
I'm really tempted to start scoping all PML nodes as
entity.name.tag
, and prepend to each scope.block-node
or.inline-node
, followed by the node.<name>
and.being
or.end
. The reason for this is thatentity.name.tag
is an exceptional scope used for HTML and XML docs, which follow a different convention from normal programming languages.THe PML syntax is definitely close to HTML in many respects.
By enforcing the
entity.name.tag
convention on all nodes, PML will be highlighted properly with any colour scheme, and we'll be able to further control highlighting through the custom scheme of the package, via the additional scope segments.Probably, in terms of native editor features and third party plug-ins being able to work with PML, this only really concerns attributes types (e.g. strings, dates, chapters headings/titles, etc.), which are already being scoped as required.
On the other hand, in terms of package maintenance and ease of third party plug-ins, adopting a standard convention for naming PML scopes would simplify things greatly. E.g. being apple to target block vs inline nodes thanks to the
entity.name.tag.block-node
andentity.name.tag.inline-node
prefixes allows to easily target whole groups of tags at once; and specific nodes can be further tracked down by their names.The
.being
and.end
scopes are rarely used with tags, but for us it means being able to trace when and where tags start and end (e.g. in custom plug-ins), so I deem it a worth addition.Of course, there are also the various
meta.
scopes that come into play, but these are not really a problem since they don't affect colour schemes, and I'm already sticking to the guidelines for these, as much as I can.As for the default colour schemes to include with the package (initially just a Dark one, but then also a Light version), after doing some local tests and playing around with various possibilities, I wanted to share with you some considerations and ask you what you'd expect from a native colour scheme.
My general idea was to colour block and inline tags using different colours, so that it's easy to visually spot them while editing.
I'd also like to add to Chapter titles a background colour that contrasts with the default BG colour, so that titles stand out from the rest of the text.
Similarly, inline code should be BG colored, as well as verbatim blocks like
[code
,[html
,[input
and[output
block contents. HTML blocks are going to be syntax highlighted too, but I was thinking of keeping its colours down to a monotone-scheme (e.g. only tints and shades of a same colour).This would be quite similar to how the AsciiDoc and Markdown packages work (especially the former), although the latter tends to use a reduced set of colours and be more on the monotone side, whereas AsciiDoc is quite colourful.
What's your take on a colour scheme? Colourful or monotone?
What would be the reasonable limit in terms of adopted colours?
The risk is to end up with a syntax that looks like a lit Christmas tree, if we use too many colours. But, on the other hand, couloirs used wisely can provide powerful visual cues for editors.
As soon as I've made up my mind on the scope naming conventions, and fixed them accordingly, I'll be able to add to the package a default Dark theme, which should be enable by default. Once the scheme is in place, of course all feedback will be easier.
Beta Was this translation helpful? Give feedback.
All reactions