Color Schemes and Scopes

[tajmone]

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 that entity.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 and entity.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.

[tajmone]

All Nodes Scopes Refactored

OK, I've managed to enforce the new scope naming convention on all nodes currently supported by Sublime PML:

• entity.name.tag.inline-node.<NODE_NAME>.begin / .end
• entity.name.tag.block-node.<NODE_NAME>.begin / .end
• entity.name.tag.block-node.raw.<NODE_NAME>.begin / .end

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 .tag.inline-node. and .tag.block-node.).

For "raw-text" block nodes (see #24) I've also added an extra .raw segment, which allows to target all nodes of this type via .tag.block-node.raw. (currently, only [code and [html are implemented).

[pml-lang]

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.

I've started working on a default colour scheme

Great!

initially just a Dark one, but then also a Light version

Good.

colour block and inline tags using different colours

Yes, that's useful.

add to Chapter titles a background colour that contrasts with the default BG colour

Very nice to have.

inline code should be BG colored, as well as verbatim blocks

Sounds good.

HTML blocks are going to be syntax highlighted too, but I was thinking of keeping its colours down to a monotone-scheme

I agree. Too much color disturbs.

What's your take on a colour scheme? Colourful or monotone?

Personally I don't like schemes with too much different colors. I find it more disturbing than useful.

What would be the reasonable limit in terms of adopted colours?

I would expect to have different colors for:

• block node tags (same color for start and stop tag)
• inline node tags (same color for start and stop tag)
• attribute names, including the assignment symbol =
• attribute values
• escape sequences (e.g. \r, \u1234)
• raw text blocks (code, html, input, output)
• comments
• normal text

Maybe nice to have: special colors for typed attribute values (date, time, regex, file path, etc.)

The risk is to end up with a syntax that looks like a lit Christmas tree, if we use too many colours.

Agree!

One more point:
As it is impossible to provide a one-size-fits-all color-scheme that all people will love, I wonder how easy it will be for end-users to change colors. Some users have strong feelings about colors. Therefore, making it easy to change them (or at least provide instructions on how to do it (or just add a link to ST's docs)) would be a big plus IMO.

[pml-lang]

Alt-B didn't work, so I actually had an old version.
I've now reinstalled the package. Alt-B is ok now.

[tajmone]

Alt-B didn't work, so I actually had an old version.

That's bad news; having to update the package manually via Git is cumbersome.

Package Control settings contain some Git specific settings on how packages installed via Git should updated:

• ignore_vcs_packages — If git and hg repositories should be ignored when trying to update packages.
  Default false.
• git_binary — Custom path(s) to git binary for when it can’t be automatically found on the system and a package includes a .git metadata directory. Supports more than one path to allow users to sync settings across operating systems.
  Default [].
• git_update_command — The parameters passed to git to update a package. The remote and branch will be automatically determined.
  Default ["pull", "--ff", "--commit"].

As you can see from the default settings, Package Control should update Git packages automatically. In my configuration, I had to enable ignore_vcs_packages in order to protect my package repositories WIP from being overwritten by their origin repo, but the default was to auto-updated them.

It's worth checking those settings, just to ensure they are correct and not overridden by User settings:

• Preferences » Package Settings » Package Control » Settings

On my machine, the Package Control defaults for the above mentioned settings match those described in the docs.

I'm starting to wonder whether the Git binary is actually visible to ST on your machine — i.e. if for some reason (e.g. installation via a package manager, or using permissions, etc.) might be hiding Git's exe path from ST. In theory, ST should inherit the environment of the current Windows User.

Either that, or your GitHub credentials are failing on invocation — e.g. because they are set only for HTTP or SSH, and Package Control is using invoking Git using a different protocol. If GitHub authentication fails, so will any attempt to git pull a repository. The strange thing is that your log doesn't seem to mention errors in this regard.

The only other problem left I can think of is that Package Control might need tagged released in order to be able to update Git packages — which, from the documentation seems to apply only to packages served and installed by channels , not via Git/Hg. Having to introduce tagged releases at this early stage would mean ending up with a repository with a lot of Alpha releases which introduce rather small changes.

It would have made more sense to start creating tagged releases once the package was more mature, but if we can't otherwise ensure that the installed package is self-updating, then I'll have to take that route — basically, you've been using the initial version of the package all this time, missing out all the various features that I've added in the course of time; this is not good for neither end users nor for me, since I need feedback on how development is progressing.

[tajmone]

It looks like I was wrong, Package Control won't update package installed this way. See this post:

• https://forum.sublimetext.com/t/auto-updated-packages-outside-of-sublime-installer/4652/3

(most embarrassing, I actually participated in that post, but forgot about it)

It seems that the correct way to go about it is to:

Just use the Package Control command “Add Repository”, and enter the URL for the github package, and it will allow you to install it through Package Control, and it will keep it up to date.

Before updating the repository instructions, could you please delete your Sublime PML package, re-install it that way and then confirm that it works — you should see in the ST console log some messages concerning Git pull operations for Sublime PML.

I'm sorry for this inconvenience, but since I only have Git packages which are mine (and are excluded from updating) I've never actually had a chance to test how this works.

[pml-lang]

I followed the instruction from Travis Heeter at this question to install the SublimePML package. (Note that I first had to install package control.)

However the Sublime-PML package doesn't work now anymore.

More info:

• When I execute 'List Packages' then Sublime-PML is displayed in the list.
• There is a file AppData\Roaming\Sublime Text 3\Installed Packages\Sublime-PML.sublime-package
• However, there is no sub-directory PML in AppData\Roaming\Sublime Text 3\Packages.
• When I start ST and open the console, ST displays the following lines related to packages:

packages path: /C/Users/Christian/AppData/Roaming/Sublime Text 3/Packages
zip path: /C/Program Files/Sublime Text 3/Packages
zip path: /C/Users/Christian/AppData/Roaming/Sublime Text 3/Installed Packages
ignored_packages: ["Vintage"]
git: using configuration from C:\Program Files\Git\cmd\git.exe
plugins loaded
Package Control: Skipping automatic upgrade, last run at 2021-07-01 15:18:14, next run at 2021-07-01 16:18:14 or after

No errors are displayed, but the Sublime-PML package doesn't work (no syntax highlighting when I open a .pml file)

I tried to remove and reinstall the package several times, but I'm not able to get it work. The cause might be the lack of sub-directory PML in AppData\Roaming\Sublime Text 3\Packages.

[tajmone]

Thanks for the feedback, it was very useful in confirming some doubts I had in mind.

Problems With the StackOverflow Instructions

I followed the instruction from Travis Heeter at this question to install the SublimePML package.

There are two problems with his instructions:

1. It's a package for a repository which is registered with the official Package Control channel (i.e. Package Control can get additional settings info from the channel JSON registry).
2. The repository and package names are the same (ChainOfCommand), whereas in our case the repository is named Sublime-PML and the package PML, which affects search paths for colour schemes, syntax tests, etc.
3. The ChainOfCommand package is a Zipped package, so it installs in the Installed Packages\ directory, whereas Sublime PML is currently non-Zipped, so it should go in the Packages\ directory instead.

Why It's Still Not Working

No errors are displayed, but the Sublime-PML package doesn't work (no syntax highlighting when I open a .pml file)

This is due to points 1 and 2, for it's looking for the colour schemes (and other important files) in the wrong path.

I really don't know how to get out of this situation, and the Package Control documentation is of no help in this respect. Its guideline state that a package should not contain the Sublime word, which means that the repository and package names usually differ, which is something that you can correct thanks to the package JSON settings you submit when registering a package to the official Package Control distribution channel.

The problem is a conflict between the official guidelines and repository needs, when it comes to naming the repository vs the package (I just can't name the repository PML, it need the leading Sublime specifier), along with the fact that there are no repository enforceable settings. The official documentation doesn't provide explicit guideline for developers, it's just assumed that packages are intended to go in the official channel (or a third party channel).

But since Sublime PML is not yet read for submission, the only ways to install it are:

1. As described in my instructions, which force the folder name to match the package and not the repository. But then it won't self-update because it wasn't installed via Package Control.
2. As described in the instruction you've just followed, which end up breaking the package.

Keep in mind that there are no package JSON settings which can be added to a repository (if I've understood correctly), since all settings are submitted to the channel, including the settings which map a repository name to the correct package name (which determines the folder name where it will be installed). So I don't see how I can fix this without registering the package on the official channel.

Registering the Package on the Official Channel

Registering the package now is going to be problematic, for various reasons:

• Package Submission is a fairly long process (from my experience, at least a month, if not more), due to the sheer amount of packages queued up. Reviewers exchanges can easily end up taking up to four weeks between one communication and the other (Q&A), before the package submission PR is merged in.
• Alpha and Beta packages are usually turned down, they want only polished material to go on the official channel. Many of the current features (e.g. enforcing settings for test purposes) are a big "no no" on the official channel.

Course of Action...

I'm going to try to contact Sublime HQ support and Package Control's author @wbond on this, hoping they can help me out — technically speaking, the Sublime Forum doesn't offer support for Package Control, which is still a third party tool, but hopefully I'll get some help.

My best guess so far is that the only viable solution right now would be for me to fix all package paths in the repository, using the actual folder names that would be created by installing it as you did (i.e. Sublime-PML), but this would still not solve the issue of the package not being Zipped on my ST instance, but zipped on users machine who installed it via Package Control as a repository. Also, it would mean having to change them again when I submit the package.

The only other alternative I can think of, is keep using my original instructions and expect end users to manually update the package via Git. This is definitely going to be a big turn-down for many users, which ultimately will result in me getting no feedback for the package.

I had already mentioned in the past that when it comes to documentation ST is a disaster: official documentation is extremely thin and vague, and you end up running in circles for ages looking at old forums posts which may no longer apply to current versions of the editor.

You can easily understand why so many long term ST users have migrated en mass to VSCode when it came out. Features and performance are not everything that matters; VSCode has a much better official documentation (to which users can contribute), and it's also free and open source.

Believe it or not, up to this day ST has never published any official guidelines to how its custom internal RegEx engine works, which is used for creating syntaxes. You simply don't know which features it supports, until you get a warning during a syntax test, mentioning that you're using some unsupported construct (e.g. lookbehind assertions).

(Note that I first had to install package control.)

That's strange, I though that Package Control was being natively shipped with ST since ST3, and only ST2 had to install it. But I had ST on my machine for so many years that I just don't remember this step. I guess that there's at least a native menu for quick installation (since I noticed it while looking through the menus sources).

Anyhow... I'll try and see if I can find a solution to this mess. But, frankly, I'm quite pi***d off at all this noise and wast of time which is taking away a lot of precious time from actual development of the package (which is already scarce). I'll probably just amend the main README, asking people NOT TO INSTALL the package, and wait for it to be available on Package Control, and carry on working solo, without any feedback (I must just as well close Discussions and lock PRs at this point).

Or maybe we should just give the middle finger to ST, abandon this project and focus on VSCode — most of my ST packages have been created for my own use, and I never even intended to publish them on Package Control.

I simply don't have the time to go through the endless round-about quest of searching decent answers to fill in the gaps of official ST documents, every time, day-in day-out. This week I spend more time trying to solve this issue than actually working on the package itself.

As you've already experienced, most of the answers you'll find in forums are not exhaustive, or they are old and deprecated, and there's always a but, and lots of variables to be considered in any context.

[celtic-coder]

Hi Tristano (@tajmone),

I initially followed the installation instructions as given in the main README.

I then removed the "PML" folder created by the git clone command and tried the Add Repository command. However, I got the following errors when I restarted Sublime Text:

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 git clone command. Note: My Sublime Text is at build 4107.

Kind Regards,
Liam

[tajmone]

As expected, this is due to the folder name differences.

I presume that there should be another command for Sublime Text to "forget" about the files installed via the initial "git"?

I wish there was! But the ugly truth is that there isn't one. When I changed the repository and folder name in another package, recently, I was getting all these errors, which come from the cache. The only bullet-proof solution is to delete ST's cache file (but you'd loose all the memorized path for Quick opening projects, amongst other things). What I did was to manually search and replace each path in the cache file (which is a JSON text file) using another editor (with ST closed), but that's not always a smooth solution either, and it requires usually more than one intervention.

I (along with others) have been asking ST devs to add a feature to handle these problems, or that ST should at least auto-forget missing paths ... but to no avail. I originally thought of creating my own tool to fix this, by parsing the JSON cache file, spotting broken paths and ask the user for their new location or whether to delete them. But then I though, "Is it worth it?". Short answer: NO, it isn't. Not since VSCode came out.

Really, there's no sound justification for keeping using Sublime Text instead of VScode. Yes, it's more performant, tons of nice features, etc. ,,,, but there's more to a software than that — especially user friendly documentation.

Sublime Text was never documented properly, and there's no reason to believe it will ever be. There's a tendency to just confide that third partied will create unofficial docs, and then they'll be linked from ST website. The problem with that is that there are no guarantees that these unofficial sources will be up to date with the latest ST changes (which indeed is often the case), and often many aspects of the documentation are guess work, since we're left in the dark of many of ST's features (old and new alike).

It's a mentality problem, and I don't think it will ever change. VSCode, on the other hand, had the courage to open up their official documentation sources to end users contributions, which means that anyone can improve it but that official developers are still responsible for its quality. With ST, on the other hand, there's no willingness to entrust users with a repository for official documentation (I asked to open contribution to the Wiki of the official bugs and issues repo, but it was turned out). Their policy is that if they see some third party documentation that looks good, they'll link to it, but are not responsible for it.

Here we're dealing with a similar problem, with Package Control being a "third party" product, for which ST is not responsible, although it's so intertwined with ST that it's almost inseparable from it. And, btw, Package Control's dev and maintainer happens to also be an employee of Sublime HQ, even through he created the package long before that.

It's really all entangled, and I find it hard to believe that it has to be so hard to create a package and be able to use it before submitting it to the official channel. Contradictions between guidelines and real-case usages aside, there's also another huge problem with Package Control, i.e. that each package must have a unique name.

So, for example, the "official" AsciiDoc package for ST registered on Package Control has been totally broken for ages (as in barely usable), but it won't be ever updated because it's syntax is used by GitHub for syntax highlighting. Unlike the VSCode Marketplace, were package with the same name can coexist, because packages are presented alongside with their author's name (as in user/repository), with Package Control adding another (working) AsciiDoc package would be problematic, for it would have to be called something else.

My advise, use VSCode. Many ST users have abandoned ST in favor of VSCode. The reason I keep updating my ST license is because I became stuck with this editor, due to all my custom settings and packages which I need for my daily work, and because I use Sublime Merge for Git, which integrates well with ST. For me, migrating to VSCode is going to be a long process, with old habits needing to be adjusted, and custom syntaxes and helpers needing to be ported. I don't know if I'll ever find that kind of time. Also, when I got involved with ST VSCode didn't exist, there was only Atom, which was really slow at the time.

I'm going to update the README document tonight, keeping the current installation instructions and explaining that the package won't self update. I'll discourage users from installing it, and warn them that if they do they should come up with some scripted solution to automate Git pulling updates. After all, right now I was hoping to gather contributors, which means they'll have to fork the repository and install their own fork, and update it manually by pulling updated from the upstream into their fork, each time.

I don't think I'll publish this repository on the Package Control channel in the future. So far, I've published only one of my packaged, the rest I simply don't care, I use them myself and others can do what they want with it. For me, this package is useful for my everyday workflow, and as a training ground for handling the PML syntax. In the future this knowledge could be used to create a PML package for some better editor, like VSCode, Atom, etc.

[pml-lang]

Considering that:

when it comes to documentation ST is a disaster
many long term ST users have migrated en mass to VSCode
VSCode has a much better official documentation (to which users can contribute), and it's also free and open source

... and:

• VSCode is the most popular editor, and at least twice as popular as ST (if we can believe statistics like this one and this one)
• a search for 'vscode vs sublime' reveals that most people prefer VSCode over ST

... 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

abandon this project and focus on VSCode

And:

this knowledge could be used to create a PML package for some better editor, like VSCode, Atom, etc.

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.

[tajmone]

• VSCode is the most popular editor, and at least twice as popular as ST ...
• a search for 'vscode vs sublime' reveals that most people prefer VSCode over ST

the main reasons for this are:

• VSCode uses a full-fledged browser engine, which means you can:
  • preview HTML documents directly in the editor, without relying on an external browser (e.g. for documentation, converted HTML/PML docs).
  • decorated source files with the full power of cutting edge HTML and CSS.
• Language Server Protocol:
  • the LSP standard is built around VSCode.
  • ST doesn't yet fully support LSP, and although ST4 does introduce some new API functionality to improve LSP support, officially it's not going to natively support LSP.
• VSCode is free and open source.

Obviously, LSP is one of the best thing that happened to editors in a long time, and IMO it's the future of syntax highlighting. True, it's hard to create a good Language Server (possibly even harder than creating a normal parser for a language, due to real-time performance expectations and fault tolerance), but we're already seeing many popular languages offering an official Lang Server, due to the wide success of LSP, and the fact it's now being supported by many editors and IDEs.

We already agreed that creating a PML Lang Server is our ultimate goal (one package for all editors/IDEs); it's just that it's going to take time to implement one (and, possibly, it's worth postponing it to when PML core is more stable, i.e. when no more breaking changes are expected, and updates might only add new nodes or attributes).

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.

I will still work on Sublime PML, because switching from ST to VSCode is going to be a long process for me — after using ST and Sublime Merge for so many years, I've achieved a level of speed in production which is going to take me months, if not a year, to achieve in VSCode, due to having to learn all the different features, keyboard shortcuts, and having to implement my custom packages, snippets, etc.

Also, the current problem with Sublime PML is that there's no way to ensure it self-updates on third party machines, due to difference in the package's path. But once the package reaches maturity, submitting it to the official channel would solve the problem. When (and if) Sublime PML naturally reaches a mature state, it's worth submitting it (and cross fingers that it gets added/accepted within a few months), I simply wouldn't count on it, and certainly won't be compromising on changing the package to bend it to all the absurd (and conflicting) guidelines of Package Control and ST (almost all of the most popular ST packages violate the scope naming rules and other guidelines, which is why they are good packages).

My main worries with a VSCode package are:

1. Not having previous experience, I'll have to learn from scratch how its syntaxes work (although they seem very similar to ST2 old syntaxes).
2. I couldn't find a syntax test system.

The latter is very important. VSCode official documentation only mentions ways to manually debug how source files are highlighted (scoped). ST's native syntax testing engine is really a blessing when building new syntaxes, for it allows developers to ensure that newly added elements don't break previously implemented ones (which happens often). I tried googling this, but I just couldn't find any similar testing solution, which basically means I'll be working in the dark when developing the PML syntax, which ultimately makes it really easy for bugs to sneak in.

The syntax tester is one of the main reasons why I'll keep working on Sublime PML, since it allows me work out the best way to capture elements; this knowledge (as already said) can then be transposed to other editor syntaxes.

VScode has the advantage that you can hook-in the parsing process via the API, to further correct scoping of edge cases. Also, it appears that Lang Server functionality can work in couple with a basic syntax definition (not sure why, but there seem to be benefits from this).

I'll start looking into VSCode, and try to come up with a new PML package. Since the latest refactoring of the syntax (mentioned above), the new parsing system is much simplified now, so it shouldn't bee to hard to begin with. Also, ST can export a .sublime-syntax file to the older syntax, in either JSON or YAML, which would provide us with a good skeleton to start off with.

Unfortunately, I didn't make much progress on the LSP front. I was hoping to find an LSP library for a compiled language that I feel confident working with, but didn't find any, which left me with the burden of having to implement the whole JSON-RPC interface and LSP protocol (didn't get really far yet, it's quite a lot of work). But even with the LSP interface in place, writing a full parser is a challenge beyond my current programming knowledge (especially the error tolerant part, which further complicated things).

[tajmone]

Updated Installation Instructions

OK, I've amended the Installation Instructions section, clarifying that the package won't self update, and that end users need to come up with some scripted solution to git pull the repository in the Packages folder.

Honestly, for those interested in the package it shouldn't be too hard to create a script that CDs to the Sublime-PML folder and pulls the updates. It should even be possible to add a simple Python script that does exactly that when ST starts up. I can't really test this since the source of the package is my local folder — I'd have to setup a stand-alone ST instance to test it, but life is too short to waste it this way.

I've also added a new Package Roadmap section, where I basically resume the thoughts and feelings that came out of this discussion, i.e.:

• Our focus will soon shift toward creating a VSCode PML package.
• Our ultimate goal is to create a PML Lang Server.
• Once a PML Lang Server is available, Sublime PML will either be refactor to make use of it, or it will be replaced by a new package that does so.

In that section I also provide one of the links that @pml-lang posted, showing that VSCode is the most popular editor, and I explain the various problems with ST which (IMO) are a good reason to migrate to VSCode.

It's already been stated that ST4 will not officially support LSP, but will add some new API features to make the task easier — in other words, they are expecting LSP support to be implemented by the community, so they take no official responsibility on it, its quality and maintenance.

I'll never fully understand this policy of delegating important things to the good will of the community. For the documentation it's the same; since the ST2 era, the official ST website has offered links to the community documentation, because it has always been known to be better than the official one.

Even the package manager, Package Control, is not an official tool, but was developed by a user from the community. Yet, without the unofficial docs, the Package Control tool and service, and all the open source packages that you can install by it, Sublime Text wouldn't be such an appealing editor. It's the huge number of open source packages (the rich ecosystem that revolves around ST) which has made the editor so popular.

I simply can't grasp how not embracing LSP, by natively supporting the protocol, is going to be a good choice in the long term. Most modern editors are supporting LSP out of the box, and not just the big editors and IDEs, but also many Indy editors maintained by single developers.

Why on earth should anyone invest energy in editor-specific packages once there's a Lang Server for any given language? LSP is such a key feature that you simply can't delegate its support to third parties, IMO. What happens if the creator of the LSP package migrates to another editor, or simply looses interest in its maintenance? Open source package go stale all the time, it's normal, that's why they are released in the open in the first place, so others can take on their maintenance. But it's also why I'd argue LSP has to be natively supported.

My guess is that it's because LSP is what made VSCode's ascension so fast, causing many ST users to migrate. After all, both LSP and VSCode are two prodigies from MS, and it's hard to compete with VSCode when it comes to LSP, since it's the official editor on which LSP features are rolled out first.