search

congo-cc / congo-parser-generator

The CongoCC Parser Generator, the Next Generation of JavaCC 21, which in turn was the next generation of JavaCC
https://discuss.congocc.org/
Other
36 stars 11 forks source link

IDE/Editor Support for CongoCC #18

Open stbischof opened 1 year ago

stbischof commented 1 year ago

I am looking for an Simple Editor that helps me to write cc files.

Javacc /jj seems to have some Support for Eclipse. Eclipse-Plugin: https://marketplace.eclipse.org/content/javacc-eclipse-plug Repo: https://eclipse-javacc.sourceforge.net/ git: https://sourceforge.net/p/eclipse-javacc/code-git/ci/master/tree/ EditorSrc: https://sourceforge.net/p/eclipse-javacc/code-git/ci/master/tree/sf.eclipse.javacc/src-plugin/sf/eclipse/javacc/editors/JJEditor.java

intellij has also a plugin Plugun: https://plugins.jetbrains.com/plugin/11431-javacc Repo: https://github.com/oowekyala/intellij-javacc Issue: https://github.com/oowekyala/intellij-javacc/issues/28

Is there any Editor? If not. What would be a good starting point?

revusky commented 1 year ago

Well, obviously, it would be great to have some tooling. I am well aware of the two plugins you link above, the one for eclipse and the one for IntelliJ. And I have been in touch with the people behind both of them. Probably if you were going to fork one as a starting point, the IntelliJ one is better. The problem with that (not exactly a problem per se) is that the IntelliJ plugin is written in Kotlin. And, for me, that is a bit offputting because I don't know Kotlin. (I would like to know Kotlin, but I have so many other things to do that...)

Well, personally, I mostly (actually, almost exclusively nowadays) edit code in VSCode. Somebody who, at some point, was interested in working on a VSCode plugin is Angelo Zerr, who is at Redhat. You could write him an email at angelo.zerr(at)gmail.com and see if he is still interested. (You could cc me if you want. Up to you...) In any case, he would probably be helpful at least, like answer questions you have. He might have some initial work that could be used as a starting point too.

Frankly, in terms of the authors of the two plugins you link above, well.... Oh, before I forget to mention it, the issue you raised there, https://github.com/oowekyala/intellij-javacc/issues/28 is, I guess, a duplicate of number 21, from a year ago: https://github.com/oowekyala/intellij-javacc/issues/21 and you can see how that went.

I reached out to oowekyala (Clément Fournier) in early 2020 not long after I decided to resuscitate my old FreeCC work. Initially, he seemed quite enthusiastic about working on this. In fact, shortly after that initial contact, he put in his roadmap that he was going to support JavaCC 21, but then, not long after that, he just went silent, stopped answering my emails, and it became clear that he had no intention of talking to me any more or acknowledging my work either. There was no real warning of this and it was really quite a shocking experience. As far as I can see, he decided to apply cancel culture to me. By the way, Fournier is one of the main developers in the PMD project which uses the legacy JavaCC quite heavily. By coincidence, just a few days ago, I came across this file which is an ant file (though I guess they invoke it from Maven) to invoke JavaCC. That is kind of interesting to look through. That file makes heavy use of the replaceregexp ant task, 34 separate usages in there, and also another dozen uses of just the regular replace ant task. Well, my point about that (and maybe I shouldn't say all this in public but I do...) is that Fournier seems to resent me so much that he continues using the old legacy JavaCC, in conjunction with all these horrific regexp kludges, rather than do what he obviously should do, which is just move to the more advanced version of the tool. (Then he wouldn't need any of these kludges. And it's not just the regexp kludges. There are a whole bunch of other horrible things that he would have no need for if he used the more advanced tool.) Well, the normal explanation would be that he doesn't know about the more advanced tool, but we know that is not the case.

So he saddles himself with this really quite obsolete broken legacy JavaCC in the full knowledge that there is a more advanced version that addresses all these problems. One might ask why. As best I can figure, I committed some cardinal crime at some point: I tried to tell him something.

But even all that said, I would consider it more promising (though not very) to approach that guy than the people behind the Eclipse plugin. Of course, one does not absolutely need the collaboration of any of these people. One can just pick up their work and fork it. What prevents me from doing that in the case of the oowekyala plugin, aside from me not really having the time to devote to that, is that it is written in Kotlin, which on top of learning the whole IntelliJ plugin API, makes the learning curve on that seem just too difficult.

But, look, on the topic of IDE support for Congo, maybe you could do this. Start a new topic on discuss.congocc.org where we could discuss what some desired features are. We can try to see if Angelo Zerr would at least participate in the conversation. I think that Angelo has a lot of specialized knowledge about developing plugins for VSCode and Eclipse.

stbischof commented 1 year ago

Im still thinking what the best way is.

Currenttly i evaluating xtext for creating a languageserver. that would fit all ide.

revusky commented 1 year ago

Oh, I think I forgot to tell you that I created a repository for experimenting with this kind of thing: https://github.com/congo-cc/IDE-Plugin

I can give you commit rights if you want. In any case, there is nothing there right now. Maybe if we just put in one or more skeletal plugins and maybe the thing could take on some life.

One general observation I would make is that you would sometimes have a choice between implementing something via some sort of regexp approach -- I mean in particular syntax highlighting -- and doing it by actually using the AST that congo builds. In principle, we are much more interested in being able to reuse the AST, or anything else that's internal to Congo, rather than implementing things like regexp kludges.

Of course, it might be that there would be some need to enhance/adjust some things internally in CongoCC itself to support any work on any given IDE plugin. But we can do that. Also, this could be a real opportunity to get the fault-tolerant parsing more polished. Anything of this nature really does need that.

adMartem commented 1 year ago

Having done language plugins for Eclipse, and having used the Javacc one (once), I believe the easiest path, by far, would be to do a Visual Code editor extension. This would include (I believe), a TextMate "grammar" definition (for coloring and folding, essentially) as a first step. That could be used with the standard editor, as well as any later Congo-specific editor. Probably the next step would be a language server implementation to provide error detection, followed by a debug server to provide the ability to actually run and debug the generated parser. At some point, as Jon mentioned, I suspect a Congo-specific editor would be in order, to provide coloring and more exotic editing capabilities based on the real grammar. Anyway, just my thoughts on this.

The problem with Eclipse, and to a lesser extent IntelliJ, is that the functionality is highly distributed among the various pieces of built-in Eclipse "generic" functionality that it must interact correctly with via events. This is/becomes a 100-ring circus very quickly. I believe VSC is organized much more simply and the parts are much more independent and loosely-coupled.

stbischof commented 1 year ago

But all 3 could use a languageserver. And xtext Support languageserver aswell as Eclipse Plugin.

Could you share your experiences @HannesWell

angelozerr commented 7 months ago

IMHO, I think IDE toolings should :

I had worked on that for JavaCC21 in https://github.com/angelozerr/javacc21-ls

This repository hosts:

You can find the textmate and language configuration (with manages auto close, matching brackets, etc) at https://github.com/angelozerr/javacc21-ls/tree/main/vscode-javacc21/language-support

Please note that language configuration (matching bracket, autoclose, etc) can be used too in IJ, Eclipse and vscode.

I think using XText is a bad idea. Even if XText is very powerfull, it is based on another grammar parser (I think it uses AntLR). The language server should use CongoCC

For IntelliJ topic, it exists some "basic" LSP support which are free and an official LSP support from Jetbrains which is basic too.

As I had to integrate the Quarkus / Qute template engine support in vscode, Eclipse IDE and IntelliJ, I'm developping an LSP "advanced" LSP support https://github.com/redhat-developer/lsp4ij which manages advanced features like codelens, inlayhint, ect

We will release soon this LSP support and you could use it to integrate the CongoCC language server.

CongoCC could provide too a debug support (to debug CongoCC template with breakpoint in IDE) and vscode, Eclipse IDE implements this capability with DAP https://microsoft.github.io/debug-adapter-protocol/

(I have experimented to implement a debugger for Qute and it starts working).

So many interesting topics, but badly I have no time to work on it.

Hope my comments will help you.

adMartem commented 7 months ago

I agree that xtext is not a good idea for the reasons stated.