CMake language server

[tambry]

Hi!

I'm developing my own CMake language support plugin for Visual Studio Code from scratch, as the TextMate grammar files used by twxs's plugin are ancient and not in line with modern CMake (no multi-line comments, no highlighting for newer properties, no deprecation classification, improper classification of control-flow statements, lackluster grammar definitions for certain constructs, etc).

While I have yet to release my plugin, I have noticed that your project seems to depend on twxs's plugin. I'd like my plugin to be able to also run alongside your plugin. What do you depend on from twxs's plugin? What would I need to do to make my plugin able to support your plugin?

BTW, love your plugin, keep up the good work! :)

[vector-of-bool]

The primary reason for the dependency is the cmake.cmakePath setting, which both plugins use to determine what cmake executable to use. I chose to add the dependency after a few issues were opened relating to both plugins providing that setting (See an early closed issue regarding the duplicate setting).

I'd ask that you consider contributing to twxs's language support. He's still accepting pull requests, and the only reason he doesn't have those newer properties highlighted is because it hasn't really come up.

[tambry]

I see why that was somewhat necessary. I think maybe a more sensible solution would be to have an option with a different name, but also support the option provided by him. This would allow an alternative language support plugin to work too.

I'm not sure if contributing to twxs's language supported is the right choice here. I find his code hard to read and from what I understand in a couple milestones it will be broken, if he doesn't fix it to use a new API. I also did open up 3 issues, 2 of them being for the grammar syntax. None of them received any feedback. I think it might be more sensible to have an alternative extension, that'll be properly maintained (for as long as I'll use CMake and VSC).
The issue also isn't about simply fixing a couple things about the grammar, it needs to be completely re-done. Currently his grammar simply highlights keywords no matter where they are, while mine aims to also understand scopes, how arguments work, what arguments are fit for what, provide much more detailed grammar, show deprecation notices, etc. I think re-doing the whole thing might be a better option at this point.

Thanks for the info and the opinion. If you have any other ideas, then I'd love to hear them.

[vector-of-bool]

Hmm... Would you be interested in collaborating on such new language support? I've felt for a while that it is a bit troublesome to have two extensions for CMake support. Perhaps the language support could be merged into CMake Tools for a more complete CMake experience.

At present, I'm working on a fairly large refactor to support the new cmake-server mode in CMake 3.7, which will help facilitate things like language and build system introspection. I think having newer, better, and more uesful language support will be an excellent addition. Simple things like completion of custom variables and properties is someting I've long desired in VSCode.

[tambry]

That is something that I would be interested in. I think it would be a great idea to have a newer language extensions that support everything.

In such a case it might make sense to open up an organization. What should be the organization's name? I currently grabbed CMake organization name. Maybe it might even make sense to move to GitLab. CMake Tools doesn't necessarily refer to CMake language support itself, but rather tools for CMake, so it might make sense to rename to simply CMake.
Also, CMake server mode supports sounds very useful.

[vector-of-bool]

An organization might be useful.

I've always wanted enhanced native support in VSCode (I find the existing C and C++ extensions severely lacking), and I think that being able to introspect a CMake project will open up a lot of new avenues for more tooling. I have another (very slowly advancing) project for a new Clang-based language service that would integrate tightly with this extension to obtain exact compile options and include directories, which is something severely lacking in other C and C++ extensions.

Perhaps an organization specifically for such native tooling would be useful? Or maybe something a little more laser-focused on CMake support?

[vector-of-bool]

There was a discussion a few months ago regarding a possible merge between this extension and twxs's extension. He said that he was anticipating implementing a new feature, but I haven't heard from him since. It is very well possible that he is no longer actively maintaining or working on the extension. It may be prudent to have some extension pick up on language support. The completion suggestions from twxs's extension are pretty good, but lacking in some regards. I'd like to see improvements, and I'm excited to see what kind of things can be done in this area.

[tambry]

Sorry for the late response. I think tight integration for even languages like C/C++ could be cool. Maybe you disabled exceptions using a compiler switch? Then it should probably noted on the interface. This would be of course made much easier, if the project was using CMake, so we could obtain the options through CMake server.
Also supporting other languages could be interesting and something that I'm interested in. :)

I might also note for CMake I'm kinda blocked by an upstream VSCode issue, that I'd prefer to not workaround.

I guess the next step would be to meet up somewhere sometime and discuss this the details, approach, etc. Would doing this over IRC (probably on freenode) be OK with you?

[vector-of-bool]

Communicating in real-time may prove difficult based on time zone differences, but may be possible. Email may be sufficient, or maybe I should open a gitter community? I've not used gitter, but I've seen it be pretty popular in the open source world.

[tambry]

@vector-of-bool I've never used Gitter before either. Not sure if I'd be comfortable using it. I'd strongly prefer to use Discord (or IRC), if that is fine with you. Since you mentioned timezones, I'm in the GMT+2 timezone, what's your timezone?

If Discord seems appealing, then here's a server invite: https://discord.gg/xtUX72r

[vector-of-bool]

I'm currently in UTC-7. I think IRC will be much more convenient.

[tambry]

Then let's use freenode and the channel #vscext temporarily until we can decide on a name. I'll be on there whenever I'm online.

[vector-of-bool]

Rather than make a new channel, you can just message me with /msg vector-of-bool. I'll also be hanging around #cmake and ##c++.

[vector-of-bool]

Hi @tambry. It's been nearly a month, but I'm still here. I haven't popped onto IRC for a while, but I think the timezone difference is a bit of a killer for real-time communication. I'm still eager to work on a refactored version of CMake support with greater language support and semantic analysis. Are you still interested in collaborating on such a project?

The CMake Server stuff is still up in the air because of some latent CMake issues that are preventing me from doing a supportable release.

[tambry]

Hi!

I'm still interested, but I'm afraid that at this time creating a better grammar is very hard due to the technical limitations of the TextMate grammar format, that I've discovered.
One of the main limitations of TextMate format is that it is unable to match things over multiple lines. Having things on multiple is quite common in CMake and this would prevent accurate highlighting (or highlighting at all), when things are split on multiple lines. I learned about this limitation after submitting an issue here. (Technically it is possible to work around this limitation)
I should note that the original TextMate bug I mentioned a while ago should be getting fixed hopefully for the next release.

Since VSCode itself uses Moncao, which has its own grammar format Monarch, it would probably be the best alternative, since it doesn't have any of the limitations that I have encountered so far in TextMate. Unfortunately VSCode doesn't support Monarch, but it would be possible to add support for it. There's a feature request for support for a better grammar format (or support for the ability to parse incrementally).

At this point I don't have the motivation to workaround the limitations of the TextMate format, but I would be very happy to write a much better grammar in Monarch or an incremental parser, if VSCode were to get support for one of those.