Java completion enhanced to support no insertion of method parameters

[sid-srini]

This configurable enhancement is based on end-user feedback received in oracle/javavscode#197

• This seems to be a matter of personal preference
• It is not a reflection on the correctness of the default functionality.

1. Added a user preference for insertion of method parameters in code completions.

   • "completion-insert-text-parameters"
   • default value = true
   • Also available via:
     • ide/editor.lib2: EditorPreferencesKeys.COMPLETION_INSERT_TEXT_PARAMETERS
     • java/java.completion: Utilities.isCompletionInsertTextParameters()

2. Added disabling of the above preference from the LSP client via the client config key PREFIX + "java.completion.disable.insertMethodParameters"

   • Updation occurs in TextDocumentServiceImpl.completion()

3. Added an extra arg insertTextParams in the following interface methods with the default value true:

   • JavaCompletionTask.ItemFactory:
     • createExecutableItem
     • createThisOrSuperConstructorItem
   • JavaCompletionTask.TypeCastableItemFactory:
     • createTypeCastableExecutableItem

4. Invoked the above methods in JavaCompletionTask with this parameter value set by Utilities.isCompletionInsertTextParameters().

5. Enhanced the implementations of the above methods in JavaCompletionCollector and JavaCompletionItem to insert text for method arguments when insertTextParams (or !memberRef).

   • The cursor would be placed inside the parentheses if it is not a no-args method completion.

6. Added a follow-up LSP command to the completion item "editor.action.triggerParameterHints" for showing the signature help when not inserting text parameters.

   • This is a necessary guide for the user.
   • It would not be triggered without this addition, since the trigger character '(' is not typed by the user.

7. Unrelated minor fixes in JavaCompletionCollector.ItemFactoryImpl:

   • Added the default prefix ("nbls") to the usages of the follow-up command "java.complete.abstract.methods".
   • Without this, the command would not get launched by the client.
   • Added to the builder in createExecutableItem(), the instantiated follow-up command "nbls.java.complete.abstract.methods".

[lahodaj]

I went through the patch - overall seems sensible. Added a few comments here and there. But, I think @dbalek should review - he might have some different views.

My probably biggest complaint would be that there are not tests checking the new behavior.

[lahodaj]

It might make sense to put the option name to the API, as is done for other options.

[sid-srini]

I didn't quite understand this suggestion. I refrained from adding to SimpleValueNames because the comment in EditorPreferenceKeys mentioned that the latter is meant for private keys, while the former for public, devel or friend keys.
I can move the key here if I misunderstood. Thanks.

[sid-srini]

I have removed the unrelated grammatical change in this file. Thanks.

[sid-srini]

I went through the patch - overall seems sensible. Added a few comments here and there. But, I think @dbalek should review - he might have some different views.

My probably biggest complaint would be that there are not tests checking the new behavior.

Thanks a lot @lahodaj.
I'll try to add some tests for the existing and new behaviour.

[neilcsmith-net]

Is there an IDE options UI for this?!

I'm curious at the reasoning for adding this where it is? It seems similar to the guess filled method arguments option? Between them they feel like they cover 3 states? (no fill, parameter names, guess values)

[sid-srini]

Is there an IDE options UI for this?!

Thanks @neilcsmith-net. I will try to add this.

• Currently, this is implemented only for Java.
• So, shall I add this only in the specific UI for Java within the Editor > Code Completions preferences?
• Perhaps later when someone else needs this implemented for other languages, it could be exposed there.

I'm curious at the reasoning for adding this where it is? It seems similar to the guess filled method arguments option? Between them they feel like they cover 3 states? (no fill, parameter names, guess values)

Yes, that progression in the complexity for insertions makes sense to me.

1. boolean "completion-insert-text-parameters":
   • on/off inserting parameter values
   • inserted values maybe parameter names or guessed local variables or something else.
   • possibly more widely available in different completion contexts
2. boolean "guessMethodArguments":
   • on/off guessing a value from locally available variables
   • inserted value takes effect only when the flag above is on.
   • possibly unavailable in different completion contexts

Given that the latter is already a defined preference key, it seems easier to maintain backward compatibility and a minimal state increase with the added boolean flag.

When implementing the UI above, I could try to introduce joint states for these 2. However, it may become difficult to move the first setting to other languages.

Let me know if this analysis makes sense.

[neilcsmith-net]

Sure, I agree with keeping as two boolean flags. The UI could handle valid combinations / or just visually disable one checkbox if desired. I was just curious as to the different reasons / pros and cons of where the keys are registered. Obviously the guess arguments key is in the options panel UI code itself - https://github.com/apache/netbeans/blob/master/java/java.editor/src/org/netbeans/modules/java/editor/options/CodeCompletionPanel.java#L52 Let's let @dbalek review that.