Configuration option to enable/disable auto activation of the completion proposal pop up

[rubenporras]

It is not possible to disable / enable the auto activation of the completion proposal pop up or to configure it. Many users will prefer to have the feature disabled or with another delay, given that a popup can interrupts flow while typing.

The values are currently hardcoded in the Generic Editor (see GenericEditorContentAssistant.GenericEditorContentAssistant)

        setAutoActivationDelay(0);
        enableColoredLabels(true);
        enableAutoActivation(true);
        enableAutoActivateCompletionOnType(true);

The proposal is to have a UI menu like in the JDT:

for the properties that the Generic Editor offers

[rubenporras]

@mickaelistria , is the proposal of creating an UI for the generic editor a good one? I think this editor does not have an UI. Should it rather be an extension point so that would be used in org.eclipse.ui.internal.genericeditor.ExtensionBasedTextViewerConfiguration.getContentAssistant(ISourceViewer) to be able to have an own custom IContentAssistant?

That would mean adding an xsd to eclipse.platform.text\org.eclipse.ui.genericeditor\schema, right?

[mickaelistria]

I would rather avoid providing tons of options. I'm more curious about "given that a popup can interrupts flow while typing", is there some bug to fix there? Most IDEs to have auto-completion popups and people usually don't complain, so maybe there is something that Eclipse IDE does wrong and we can improve without options?

[rubenporras]

Regarding " is there some bug to fix there", yes, I think there are two (or three) bugs in there:

• One I filled already: https://github.com/eclipse/lsp4e/issues/660
• The second one is that when the popup appears and shows "Computing Proposals", pressing arrow down/up does not allow you to go to the line below/above in the code.
• The third one is that the dialog hides the text below, and it is by default a multi line dialog, which hides quite some text. Even if the popup disappears after some millisecs, it is distracting to see a pop up appearing and disappearing while typing.

The last two would be addressed by https://github.com/eclipse-platform/eclipse.platform.text/pull/210

Then there is the problem that it is triggered too often (basically on any character which is a letter or a number), and without delay. I do not know about any editor that does that. That highlights the bugs above and also puts a lot of stress on the server.

The JDT does not triggers on each alphanumeric character by default (as seen in the screenshot above, only after '.'). I have checked VSCode and it also has by default more conservative configuration:

That is delay of 10 instead of 0, only triggered on trigger characters instead on of each alphanumeric character, and not triggered inside of strings and comments. This defaults are in my opinion better, and are very similar to the defaults of the JDT. The main difference is that VSCode has a delay, which makes sense if one is communicating with a server.

Nevertheless both the JDT and VSCode allows the user to configure it.

[rubenporras]

Finally, regarding the default configuration, I have created https://github.com/eclipse-platform/eclipse.platform.text/pull/214.

[ghentschke]

Then there is the problem that it is triggered too often (basically on any character which is a letter or a number), and without delay.

I agree that this is very annoying. Especially on large files with LSP based editor it can be a performance issue as well. It can be fixed by setting org.eclipse.jface.text.contentassist.ContentAssistant.fAutoActivateCompletionOnType to false via GenericEditorPreferenceConstants.CONTENT_ASSISTANT_AUTO_ACTIVATION_ON_TYPE.

This preference setting is unfortunately hidden. When set to false, the auto-completion is triggered only by the trigger chars e.g. delivered by the language server in org.eclipse.lsp4e.operations.completion.LSContentAssistProcessor.getCompletionProposalAutoActivationCharacters().

I am not sure how to make this preference accessible to the user. I would appreciate a new preference page for the generic text editor or creating a extension point as mentioned in #916.

IMO these three preferences should be modifiable by the user: GenericEditorPreferenceConstants.CONTENT_ASSISTANT_AUTO_ACTIVATION GenericEditorPreferenceConstants.CONTENT_ASSISTANT_AUTO_ACTIVATION_DELAY GenericEditorPreferenceConstants.CONTENT_ASSISTANT_AUTO_ACTIVATION_ON_TYPE

As a IDE user I am expecting that I can change the behavior in my editor (The current Java and an C/C++ editor settings in Eclipse allow it as well)

[ghentschke]

What about an extension point which overwrites the preferences for a given content type? E.g. cdt-lsp project will provide auto-completion preferences for C/C++ content types.

[mickaelistria]

We may try to just expose the delay, and our smart users will set a high value for it. which would be equivalent to disabling the auto-assist.

The hardcoded delay of 0 is a probably a too hardcore one, there are some better values when it comes to such feedback. We should start by considering another value, such as 300ms (a bit more than the usual delay before 2 combined keystrokes) which is supposed to prevent from useless requests while user is typing continuously.

What about an extension point which overwrites the preferences for a given content type?

One difficulty with preferences is to decide what has higher priority in case there are multiple unrelated sources: imagine your extension point sets a preference for content-type, but a local project setting does set to a different value, which one would win?

@ghentschke In the case of CDT, isn't the 0 delay causing the issue? ie if one types a 8 letter words uninterrupted, then 8 requests are sent to LS instead of just 1 when the user takes a break?

[iloveeclipse]

Actually this is one of the issues I've found very disturbing since I'm trying to use generic editor + TextMate for shell / xml / random other file types I have in the workspace, for which I don't want to install extra plugins.

This popup annoys me while typing, as it appears on every keystroke. If there would be any way to disable it or configure it, it would be very helpful.

[ghentschke]

In the case of CDT, isn't the 0 delay causing the issue?

I think a value of ~300ms as default would be an improvement, but I think the ability to trigger only on trigger chars would be better. IMO the user should have the opportunity to tune these settings since there are many different preferences as there a users out there.

This popup annoys me while typing, as it appears on every keystroke. If there would be any way to disable it or configure it, it would be very helpful.

Same for me.

One difficulty with preferences is to decide what has higher priority in case there are multiple unrelated sources: imagine your extension point sets a preference for content-type, but a local project setting does set to a different value, which one would win?

I think this would be the responsibility of the extension provider. I think currently all text editor settings are on workspace level only:

Why can the user set the tab with but has no opportunity to change the auto-completion settings?

[iloveeclipse]

One difficulty with preferences is to decide what has higher priority in case there are multiple unrelated sources: imagine your extension point sets a preference for content-type, but a local project setting does set to a different value, which one would win?

Most specific one, it is already the case with workspace vs project settings.

I wasn't aware we have that setting at all and it is hard coded. Best is to introduce workspace setting and use that. Whoever extends the code should either simply inherit it or be able to provide its own version.

[iloveeclipse]

Note for myself: for products, either one of preferences below need to be added to product customization so that preferences are set to the more or less non-annoying state:

org.eclipse.ui.genericeditor/contentAssistant.autoActivationDelay=1000
org.eclipse.ui.genericeditor/contentAssistant.autoActivation=false

Of course it would be better to add "Generic Editor" preferences page below "Text Editors" that would expose the preferences above to users (and whatever else hardcoded as of today in Generic Editor).

[rubenporras]

@ghentschke In the case of CDT, isn't the 0 delay causing the issue? ie if one types a 8 letter words uninterrupted, then 8 requests are sent to LS instead of just 1 when the user takes a break?

Did we not increase the delay already in https://github.com/eclipse-platform/eclipse.platform.text/pull/214/files to be 10 and not 0? Or are we talking about a different delay?

[rubenporras]

Note for myself: for products, either one of preferences below need to be added to product customization so that preferences are set to the more or less non-annoying state

If it helps, for the record, that is what we do as well.

Of course it would be better to add "Generic Editor" preferences page below "Text Editors" that would expose the preferences above to users (and whatever else hardcoded as of today in Generic Editor).

Yes, that would be nice. One could start with a generic preference for all content types, but ideally the user should be able to configure each content type different, as the preferences allow that (see https://github.com/eclipse-platform/eclipse.platform.ui/pull/931)

[ghentschke]

Did we not increase the delay already in https://github.com/eclipse-platform/eclipse.platform.text/pull/214/files to be 10 and not 0? Or are we talking about a different delay?

Yes, but I think 10ms is still very fast.

Of course it would be better to add "Generic Editor" preferences page below "Text Editors" that would expose the preferences above to users (and whatever else hardcoded as of today in Generic Editor).

Yes, that would be nice. One could start with a generic preference for all content types, but ideally the user should be able to configure each content type different, as the preferences allow that (see https://github.com/eclipse-platform/eclipse.platform.ui/pull/931)

I can start with a PR for a Generic Editor Preference page for the three preference settings mentioned above. The next step could be to support different preference settings for each content type.