Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    gayanper
    @gayanper
    That should solve your issue if i understood your problem correct :)
    Denis Loginov
    @dinvlad
    @gayanper that makes sense, thanks!
    Re listener support, are you working to expose additional methods to allow extensions, or should we also try to override something?
    gayanper
    @gayanper
    @dinvlad well additional client method, if thats what you are after, you can define it in your own LanguageClient you are providing.
    Denis Loginov
    @dinvlad
    @gayanper could you elaborate please? which method/class could I extend to listen to a custom notification from the server?
    I’m referring mostly to these set of notifications: https://github.com/microsoft/vscode-languageserver-node/blob/master/protocol/src/protocol.progress.proposed.md
    gayanper
    @gayanper
    @dinvlad you need to extend the DefaultLanguageClient and add these methods with the json annotation like its done in LanguageClient interface. The extended client class must be exposed to lsp4intellij through the extension support
    Denis Loginov
    @dinvlad
    @gayanper thanks - which methods in particular should I extend?
    gayanper
    @gayanper
    @dinvlad to which class methods are referring too ?
    Denis Loginov
    @dinvlad
    @gayanper I guess I just wanted to understand where to start when implementing a listener..
    gayanper
    @gayanper
    @dinvlad you will need a CustomeClient implementation. check this fork of mine, you will find all the details you need like the client implementation to start with at https://github.com/gayanper/sts4/blob/lsp4intellij/idea-extensions/idea-boot-java/src/org/spring/tools/boot/java/ls/StsLanuageClient.java
    Denis Loginov
    @dinvlad
    Perfect, thanks @gayanper !
    gayanper
    @gayanper
    @rasika have you given any thoughts on making this a plugin ?
    At the same time i'm also thinking make the definition to be connected files via Language than the extension
    List of Language will enable to reuse LS which supports multiple languages
    Denis Loginov
    @dinvlad
    Hi folks, I’ve configured LSP and can see messages being exchanged via server logs. The server sends textDocument/publishDiagnostics. However, the client doesn’t show any of the reported diagnostics. I added localInspection in plugin.xml according to the docs, but that didn’t seem to make a difference. Should I rather report it through a GH issue?
    gayanper
    @gayanper
    @dinvlad try the latest changes from ballerina-platform/lsp4intellij#86 (gayanper:pr/enhance-inspections ) PR branch and see if diagnostics are fixed
    gayanper
    @gayanper
    Are we dead in this group ? 🙄
    Rasika Perera
    @rasika
    Not yet 😂
    gayanper
    @gayanper
    @rasika shall we try to my latest changes in the inspection PR. I think now it should solve the delaying issue
    Nipuna Ransinghe
    @NipunaRanasinghe
    @gayanper Sorry for being dead for a while 😂 It's been a hell of a month with our language 1.0 release... I tried your latest changes and it works perfectly except now the annotator is triggered twice in each document change event. So it would be better if we can trigger the external annotator only when a diagnostics message is received. So I'll try to improve and after that, we are all good to merge I guess.
    @dinvlad Did you try with the @gayanper's latest changes? How was your experience? :)
    gayanper
    @gayanper
    @NipunaRanasinghe are you sure that there are no two diagnostic messages coming in ?
    gayanper
    @gayanper
    @NipunaRanasinghe also make sure you don't have any other annotators running as well, cause for example the SonarLint plugin does the same things like this library to re-invoke the annotators, that it restart the deamon for that file.
    Nipuna Ransinghe
    @NipunaRanasinghe
    @gayanper There's only one message is coming from our language server but the annotator is running twice for each document change event. I've added few changes to your PR with minor improvements.. Shall I push my changes to your branch if that's fine with you? Then you can verify my changes and hopefully, we can merge after that :)
    gayanper
    @gayanper
    @NipunaRanasinghe sure please do i will give you permission if its not already provided
    Nipuna Ransinghe
    @NipunaRanasinghe
    @gayanper Sure thanks!
    I just pushed my changes to your branch. Please verify it and collaborate if you see any points where we can further improve :)
    gayanper
    @gayanper
    @NipunaRanasinghe did check which caused the additional annotator invocation ?
    Nipuna Ransinghe
    @NipunaRanasinghe
    @gayanper I think we cannot avoid it since the annotators are supposed to be triggered when the file content is changed. That's why I've added a diagnostics lock mechanism to terminate the annotator in the collectInformation phase, before going to the annotation phase.
    gayanper
    @gayanper
    Hmmmm i see. So your plan is to just let the first execution which has diagnostics to handle it and let the next one exit early right ?
    gayanper
    @gayanper
    @NipunaRanasinghe What if we just drain the diagnostic list and get rid of the lock variable and do a empty check internally with a methos hasDiagnostics ?
    And how is your license permission to fork and do some major changes, like making a plugin and make it based on intellij languages
    Because i still see some problems if ppl smart to make mocktails out of this lib with different versions of thr lib in same installation with different consumer plugins.
    Nipuna Ransinghe
    @NipunaRanasinghe
    @gayanper I've already tried it earlier but it failed to update diagnostics intermittently which I couldn't dig in further. If you don't see any blockers maybe we can continue merging and do the fine tunings after that.

    And how is your license permission to fork and do some major changes, like making a plugin and make it based on intellij languages.

    I'll check with my team and get back to you :) Meanwhile, do you see any advantages of making this coupled with the language implementations instead of using the extensions?

    gayanper
    @gayanper
    Sure lets do like that. But can just name the method as "isDiagnosticsLocked" ?
    Nipuna Ransinghe
    @NipunaRanasinghe

    Sure lets do like that. But can just name the method as "isDiagnosticsLocked" ?

    Sure will do

    gayanper
    @gayanper
    @NipunaRanasinghe and @rasika have had time to think about making this a plugin thingy ?
    i really have doubts how it will behave if the same LanuageClientComponent is registered as ApplicationComponent by many plugins :(
    gayanper
    @gayanper
    @/all what do you guys think about adding a new language based server definition. It will be based on intellij language
    gayanper
    @gayanper
    Have we done a a release with all the new changes ?
    gayanper
    @gayanper
    Guys are we radio silence again :) ?
    Nipuna Ransinghe
    @NipunaRanasinghe
    @gayanper Again we had to fully focus on our language beta release :/ Our 1.0 release is due to 8th of September and after that, I'll be able to start working on missing features (i.e Snippet support) and the other fixes... Meanwhile, if anyone can contribute to the plugin, you are more than welcome! :D
    Nipuna Ransinghe
    @NipunaRanasinghe

    i really have doubts how it will behave if the same LanuageClientComponent is registered as ApplicationComponent by many plugins :(

    I've discussed this matter with one of our architects as well and as I've mentioned before, both approaches have their pros and cons... Although Making this a plugin will solve the potential of conflicting with the other plugins, we may lose the most useful feature of this project, which is extendability of the LSP for custom requirements. (One of the main reasons why we had to deviate from our good old scala plugin :/ )

    Therefore the our decision was to maintain both (library and a wrapper plugin). So in addition to the language client, we can maintain the wrapper plugin in the same repo and publish to the jetbrains plugin repository on each new lang client release. WDYT?
    Nipuna Ransinghe
    @NipunaRanasinghe

    Have we done a release with all the new changes?

    Yeah! 0.93.0 release is available on jitpack with all the new changes (I'll add the release note soon)

    gayanper
    @gayanper
    @NipunaRanasinghe great wrapper plugin looks like a good idea. Lets move forward with this.
    Nipuna Ransinghe
    @NipunaRanasinghe
    @gayanper great! I can start working on this during the next 2 weeks :) Let's get this done before the 1.0
    Oliver Nybroe
    @olivernybroe
    Hi, just found this plugin and it looks pretty promising.
    We have a new language we are starting to create and was thinking of going the LSP way.
    However, when I look at the example in the docs, there are no color highlighting, is this not supported or just not part of the example?