everything looks good so far. I did some testing with editor templates but would have to do more to be confident that this does not cause regressions.

The thing is that it take sometime (some ms) to add the () after I hit enter to see the ctor but this is a general problem I think. I just wanted to mentioned it here, because I think this is of this completion chaining stuff what you mentioned. I mean I really wanted the ctor and it still completes to new HashMap<>...~200ms new HashMap<>(). Why not just immediately?

The thing is that it take sometime (some ms) to add the () after I hit enter to see the ctor but this is a general problem I think. I just wanted to mentioned it here, because I think this is of this completion chaining stuff what you mentioned. I mean I really wanted the ctor and it still completes to new HashMap<>...~200ms new HashMap<>(). Why not just immediately?

I don't think i can reproduce this issue. The text substitution happens as fast as i can press return twice in a row. Might be influenced by the complexity of the document/project, this PR doesn't do any heavy lifting, it only tweaks the conditions when followup/parametrized completions are triggered.

I mean I really wanted the ctor and it still completes to new HashMap<>...~200ms new HashMap<>(). Why not just immediately?

because the first completion is for the type (HashMap), the second for the constructor. There is more than one constructor, therefore another completion popup opens. If there would be just one constructor it would insert it right away. Thats also why #3805 loops forever since the completion itself sets the cursor to a location which resembles the initial conditions (and there is just one item in the completion list).

edit: btw #4142 is working on removing a completion related bottleneck, but this isn't related to this PR here

I think we should implement it in the Java editor after we revert all changes for the editor.
I guess that we can handle it in the Java editor (Maybe, we should be able to run CC again from the Java editor if needed.) because the Java editor knows the context.
Did you try that?

I think fixing it in the editor(invoking CC repeatedly in it) is risky.

@sdedic @jlahoda Do you have any ideas or advice?

Add: This is my misunderstanding, sorry.

@junichi11 this isn't java specific. ${cursor completionInvoke}is part of regular completion templates.

@mbien I don't say about it. If we can implement your issue in the Java editor, we shouldn't change the editor.

e.g. call the method like the following (scheduleShowingCompletion()) in the Java editor

    private static ScheduledExecutorService service = Executors.newSingleThreadScheduledExecutor();

    private static void scheduleShowingCompletion() {
        service.schedule(() -> {
            Completion.get().showCompletion();
        }, 750, TimeUnit.MILLISECONDS);
    }

What is the delay for and why is it that high? I mean, I see for what it is, but why is it intended to be that high to wait for it?

@mbien I don't say about it. If we can implement your issue in the Java editor, we shouldn't change the editor.

again. This is not a java issue. A completion template (for any language) with a completionInvoke parameter, should open the completion if the parameter is active. This was always the case, there was just a regression in 12.3 caused by #2519 (please read the PR text and also of this PR here). So lets try to fix this properly in the editor lib. This PR is attempting exactly that, restore <12.3 functionality without causing regressions.

@mbien Ah, I see now. I thought you are working on a Java issue, sorry.

@mbien I've verified #3805 doesn't occur. Thank you for your work!

@lkishalmi Is groovy using the same API for code completion (ide/editor.codetemplates)?

We tested this PR for php and java and it looks promising.

@mbien I'm sorry, but I do not know the Groovy implementation details.

I don't feel really qualified to review this. However I verified, that the issue is gone and the behavior seems to be fixed. The changes look ok to me.

if anyone knows someone who might want to review this, please add to PR.

i would like to merge this one soon too so that it gets good testing in during NB 15 dev

Agree.