VSCode and Sublime editors

[Tony Gravagno]

When these discussions first started I create a private Google doc that attempted to define the set of features that we would expect from all editors extended to support MV syntax. Grant and a couple others took a look and we had a few exchanges about refinements. When Grant released the extension for VSCode it was such an immediate success that there was no point in continuing a document for standards. My thought was that this VSCode implementation would essentially define the standard - whatever it did would be expected in others.

So for anyone wondering about what happened to that stuff ... well, it seemed to become obsolete before it went production. I'm quite happy with that.

Ian's new Sublime support isn't the first in this area but nothing else has taken hold so I wish him the best of luck with it. We're already seeing a list of what it does and does not (yet) support, and there's no doubt that those who try it will offer requests for changes.

As stated above, in lieu of a standard definition now, I suggest that anyone who creates one of these language definitions might want to use the MV# implementation set of supported features as their own tasklist. With that, everyone knows what could, should, or might be in one of these. We won't need to ask for a feature because we can assume that the authors are aware of the features, and that they just need time to implement them. Or better, after checking with an author like Ian or Grant, it would be great if more people offer their own contributions to the code.

Given all that, would it still help if there was a defined list of features, for us to use as a guide? I'm thinking a Google sheet where:

A = feature name

B = VSCode Supported

C = VSCode name of person working on as-yet unsupported version

D = Sublime Supported

E = VSCode name of person working on as-yet unsupported version

...

If Ian doesn't put his name on a specific feature being worked on, it's fair game for anyone else.

More columns can be added for each feature, for example to describe how it's been implemented, and other related areas where there might be complications. Documentation can be as important to FOSS as the code.

And related to documentation, for the implementations that support popup help for BASIC and other syntax, there's no sense in each developer having to write out the same text for different platforms. Another Google sheet can contain a set of text for any of these projects to use.

Remember that these are not commerciall offerings, it's Free and Open Source. No one is in competition. Everyone should be open to helping all of these projects, and if one effort helps more than one project, so much the better.

Consistent documentation like this can also help with implementations for different MV platforms, with unique features, or similar features that need to be implemented differently. Is the feature implemented? Is it in progress? Are there docs? With everything in one place we don't need to worry about different projects having different repositories of ToDo/Done features.

Is this sort of thinking and organization overkill? If enough folks here believe this is of value I'll kick it off.

If you do agree that there is value in this, is a Google sheet the wrong place for it? Would a github repo be better? The tracker there can be used to document and tag bugs "Function definition not recognized : VSCODE, QM". This may not be the home for the code, but we can try to ensure that the latest version of the code is hosted or forked here to provide a single, central home for anyone who wants to compare.

And in the bigger picture... Following on the success of these IDE projects, are there any others where we might be able to do the same?

Thanks for your time.

T

[Ian Harper]

Thanks for bringing this up again Tony. I've been meaning to take a pass on the RFC and see where the Sublime plugin stands. For the most part I've been focused on building the features I want  and use so it will be good to review the RFC.

[Ian McGowan]

I don't know if this is even relevant, but how does LSP - Language Server Protocol play into all of this exciting activity?

https://microsoft.github.io/language-server-protocol/

[Tony Gravagno]

I've never even seen that. That's fascinating. Grant and his team might be familiar. I'm stretching to connect all the dots but it looks like that could facilitate extensions into MV, like ED, AE, SED, UP, TCL etc.

As to how this could play in this new ecosystem, off-hand I can picture a single LSP server that supports all MV flavors and purposes. Then it would be up to interested individuals to implement the client-side routines that use the server. With that, one person might want to implement QM syntax for any caller, someone else would implement the caller from VS Code, someone else might do Eclipse, someone else might do UPdate, etc. So, as I just suggested in another thread about push notifications from MV to mobile, separating client and server efforts makes all of this stuff a LOT easier.

I get very frustrated with cool tools like this. The DBMS companies don't do anything with them. There's no business case for someone in the field doing it because everyone expects tools for free. So we simply don't have or use a wealth of technology that could change perceptions of MV.

Lamentingly yours,

T