feat: add Beta support for Inline Completion Request

[rubenporras]

No description provided.

[rubenporras]

Adds the inline completion request as proposed for LSP 3.18 (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#textDocument_inlineCompletion).

I have added the Beta annotation as suggested in #856 but this makes tests fail because this dependency is not allowed.

There are also some problems with the javadoc which I have not yet figured out. If you are interested in the PR, I would clean this up.

Are you interested in the PR? In that case, since this is my first contribution to the project, do you see any problem in how I translated the spec to the Xtend file?

Thanks

[angelozerr]

Thanks so much @rubenporras to work on this issue. LSP4IJ (LSP support for IntelliJ) is super interested with that, we wait for this support redhat-developer/lsp4ij#643

[pisv]

@rubenporras Congratulations on your first contribution! It is really appreciated. I have already started a review.

[pisv]

@rubenporras I have completed the first round of review. If possible, please address review comments with a separate commit. Thank you for your time and effort!

[rubenporras]

@pisv, thanks a lot for the thorough review.

I have addressed all the comment but the ones about indentation being a bit off because I could not figure it out.

I have also fixed the errors reported in the javadoc when running the gradle build.

I still need advice on how to fix the problem with the Beta annotation. At the moment the annotation makes the Lsp4jArchitectureTest.testNoDependenyToGuava fail.

[rubenporras]

I have been looking at Lsp4jArchitectureTest.testNoDependenyToGuava, and my proposal would be that to avoid the dependency we can declare our own Beta annotation in a new package org.eclipse.lsp4j.annotations. That should be straightforward.

[pisv]

+1 for declaring our own Beta annotation to avoid a dependency on Guava. I think that it should be defined in org.eclipse.lsp4j.jsonrpc to allow it to be used everywhere in LSP4J, including org.eclipse.lsp4j.debug. Not sure whether we need a separate package for it. It looks like we have not had special packages for other LSP4J annotations, so I'd suggest placing it in an existing package, e.g. org.eclipse.lsp4j.jsonrpc.util.

[pisv]

@rubenporras Unfortunately, I will not be able to make another round of thorough review until next week. But rest assured that your work is much appreciated! Thank you.

[rubenporras]

Thanks for the input.

I have added another commit on top with an own Beta annotation.

I will also not be available until next Tuesday. I guess you will enjoy the Easter time the same as I :).

[rubenporras]

Thanks for the input.

I have added another commit on top with an own Beta annotation.

I will also not be available until next Tuesday. I guess you will enjoy the Easter time the same as I will :).

[pisv]

@rubenporras So, I've done my best to review your changes against the spec, and they look good to me now. In particular, I have verified that the mapping of the relevant spec constructs to LSP4J looks correct. Thank you for the great work! 👍

Let us wait for feedback from @jonahgraham regarding the Beta annotation...

[rubenporras]

@pisv , thanks for your review.

[pisv]

@rubenporras Would you push the commit with the latest changes? :-) Thanks!

[rubenporras]

@rubenporras Would you push the commit with the latest changes? :-) Thanks!

You mean, I should rebase, squash and push?

[pisv]

No, I mean that you have resolved the three final nitpicks I left after the latest round of review, but have not pushed the changes yet, as far as I can see :-)

[rubenporras]

Sorry, done by now

[pisv]

Great, thank you!

[pisv]

I approve this PR from my side, because all my comments have been properly addressed, but cannot merge it until @jonahgraham has an opportunity to review the current state and submit feedback. (By way of reminder, there is an open question about the Beta annotation.)

[rubenporras]

@jonahgraham ping on the feedback regarding the Beta annotation.

[rubenporras]

@pisv , it looks like we cannot get the review from @jonahgraham. I propose that I change the javadoc comment to something more straight forward and sidestep the problem. Do you agree?

[jonahgraham]

(Sorry for being a little delinquent here - I have been unavailable for much of the last two months)

[jonahgraham]

I don't know if copying Beta source here is ok. It is trivial, so in that way I think it is ok, but adding the apache licensed file certainly complicates things.

Can we create our own Beta class (like @LSP4JBeta or @BetaLSP)?

[pisv]

@jonahgraham Hope you are doing well, and sorry for bothering you!

Thank you for your helpful review. If I understood you correctly, the main thing about this annotation is that it needs to be implemented from scratch and contributed under the project's license. And, while the name of the annotation is probably not very important in this regard, you are proposing to choose a name different from the current Beta to reinforce that the annotation has been made specifically for using within LSP4J.

If I may still have your attention, another question about this PR or, rather, our next release in general is that would it be fine to have it merged as part of the 1.0.0 release? If I remember correctly, one of the ideas initially was that the 1.0.0 version could be released with no changes to the codebase (except the version bump itself) to set a baseline for future releases. Do you think it is still relevant? I'm asking because so far, we have not merged anything to 1.0.0, except #889. Thanks!

[jonahgraham]

@jonahgraham Hope you are doing well, and sorry for bothering you!

I am (enough) - and you aren't bothering me :-)

If I understood you correctly [...]

Yes on all accounts. Note that there is probably only one way to implement such an annotation, and that there are probably no IP issues with that one way of doing it, so I would expect that the "LSPBeta" or whatever it is called, may look a lot like guava's Beta.

If I remember correctly, one of the ideas initially was that the 1.0.0 version could be released with no changes to the codebase (except the version bump itself) to set a baseline for future releases.

Yes that was intention.

Do you think it is still relevant?

No, not really important.

The idea of 1.0 release is that from that point forward we are going to be API versioned according to semantic versioning.

[pisv]

Got it. Thanks a lot for the swift response, and all your comments!

[rubenporras]

Yes on all accounts. Note that there is probably only one way to implement such an annotation, and that there are probably no IP issues with that one way of doing it, so I would expect that the "LSPBeta" or whatever it is called, may look a lot like guava's Beta.

I think as well there is not much to deviate other than from the comment. I think it should be enough if I write the javadoc from scratch. I would keep the name Beta because it is the obvious name for it (there are other already such as org.apache.poi.util.Beta).

[jonahgraham]

No objection from me to calling it Beta.

[rubenporras]

I have renamed it to Draft, which in our case conveys better what it is

[jonahgraham]

I have renamed it to Draft, which in our case conveys better what it is

+1

[pisv]

Excellent! Thanks a lot for your contribution, @rubenporras 👍