Why are you forking LSP4IJ?

[angelozerr]

I have noticed that you have forked LSP4IJ https://github.com/hcengineering/lsp4ij and you did some fixes.

Why are you doing that? Why you don't contribute to LSP4IJ?

I will be very glad to work with you.

If you need some update of LSP4IJ, I am totally opened to do some refactoring or add some extension point to customize the current behavior of LSP4IJ.

[angelozerr]

For instance when I see your code at https://github.com/hcengineering/lsp4ij/blob/main/src/main/java/com/redhat/devtools/lsp4ij/features/diagnostics/LSPDiagnosticHandler.java I did some performance improvements in redhat-developer/lsp4ij@0ebc3a9 and I manage opened/closed document diagnostics with inspection that you should not have since your fork.

IMHO I think we should collaborate and work together.

[kosz78]

Using the original repository can be problematic because some of our modifications require changes to IDEA itself. However, we will be committed to proposing fixes and reporting problems to the main LSP4IJ repository.

[angelozerr]

Thanks for your answee!

According the code I have seen, it seems it is only to manage margin in inlay hints, right?

If it that do you think it is doable to host your custom hint format in lsp4ij ?

[n1kolasM]

While our custom hint format support fails gracefully in Idea Community now, we do not promise the stability of the API or compatibility with Jetbrains IDEs. Also we are still working on improvements to make lsp4ij suit our usage better, and our decisions may not work for a standalone plugin.

[angelozerr]

@n1kolasM I understand.

But IMHO having a for of LSP4IJ is a bad idea because LSP4IJ starts working pretty well and we have the luck to have more and more contributions and I have the intention to do again some refactoring in internal classes.

For you, it will become a nightmare to synchronize your LSP4IJ from official LSP4IJ.

I am 100% opened to provide some extension point or improve LSP API to manage your custom usecase. For instance for your inlay hint which is based on your Huly Code hint format, we can provide a factory of InlayHint with LSPHinlayHintFeatures like I did for LSPCodeLensFeatures. You could override it and use your custom HintFormat class.

For TreeSitter language which is add in SimpleLanguageUtils, oficial LSP4IJ can add it since there is no dependency to TreeSitter plugin.

If you see main base code of LSP4IJ, I did a big refactoring to support diagnostics which should improve performance (to avoid to many time the Daemon restart).

Your code is now very different from our code in LSPDiagnosticHandler and it will be more and more complicated to have the same base code.

I would like to really collaborate with you to provide the best LSP support for IntelliJ, so I hope I will convince you to give up your LSP4IJ fork touse official LSP4IJ that you could tweek with some extension point or LSP-API.

[angelozerr]

For your information, I have integrated your fixes with NullPointerException and wrong annotation with redhat-developer/lsp4ij#960

I am working on Snippet escape improvement redhat-developer/lsp4ij#962 andI will support also LSP Diagnostics in project errors (like you did).

[angelozerr]

@n1kolasM I have integrated your all fixes with Nullable + NullPointerException and fix (with a different mean) the escape snimmets.

I'm working on redhat-developer/lsp4ij#443 (by using your great stuff but again with different code because for now our code for diagnostics is different).

I repeat me but I am totally aware to integrate any feature that you need in huly-code or provide any extension point in order to you tweak LSP4IJ for your need.

My wish is that we have the same base code and we benefit together with your and my work. It is the power of the open source and the level of LSP4IJ starts working pretty well because of lot of contributions like @SCWells72 did to use it in her paid product.

What do you think about that?