EditorAction `doExecute` not being invoked when other plugins are reading same document

IntelliJ Platform
1

Hello!

I have the following class that implements EditorAction: continue/extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/autocomplete/AcceptAutocompleteAction.kt at main · continuedev/continue · GitHub

My issue is that there is another plugin (SonarQube) that users of my plugin frequently install which is reading the document on every keystroke. This appears to be preventing my doExecute overridden function from executing. I’ve tried a variety of other methods to acquire a write intent/write lock that are outlined in these docs, and also WriteAction.run, but without success.

My hunch is that I’m unable to acquire the write intent/write lock because of the frequent reads from this other plugin, but I’ve also confirmed with debugger breakpoints that my doExecute is not being invoked at all. This seems to be the root of the problem since my runWriteAction is inside doExecute.

One other interesting note is that this seems to primarily be an issue for Community Edition users but not Ultimate.

Is there a recommended way that I’m missing to await the write intent/write lock that my action needs?

3

Hi Patrick, welcome to the community :slightly_smiling_face:

I don’t understand how SonarQube’s plugin would block your doExecute(). Could you please point to some code parts of the SonarQube’s plugin that you suspect causes this?

In general, read actions shouldn’t block other actions infinitely, as write actions are prioritized over reads, so it is unlikely that many read actions will block platform code or other plugins’ actions.

Regarding not executing EditorActionHandler.doExecute() I suggest setting breakpoints around its usages in the platform code. I would start with checking what happens in EditorActionHandler.execute(). There are a few ifs there, so maybe your doExecute() is skipped for other reasons than read actions?

5

Thank you for the quick reply Karol! We realized the issue wasn’t with doExecute as you pointed out, but rather with a CaretListener we have that was being called unexpectedly and clearing our completion as a result.

Adding the following logic to the beginning of our caretPositionChanged to short-circuit that completion clear fixed things:

 if(event.editor.editorKind != EditorKind.MAIN_EDITOR) {
            return
        }

I’m not sure why that worked to be honest. I did find some similar logic on the SonarQube extension, so my hunch is that every time SonarQube is analyzing a document, a caretPositionChanged event is fired off for some editorKind that is not MAIN_EDITOR.

Thanks again for your help here though!

On an unrelated note, my team is interested in learning more about how to make the transition over the InlineCompletionProvider for our plugin. I saw recently that Oleg Taratukhin was discussing this with a Continue user on this YouTrack issue: Request to Allow Concurrent Use of Multiple AI Code Completion Plugins

If there’s any links outside of the one Oleg provided in that thread that would be useful for us, please let me know!

6

It is not covered in the SDK documentation yet, but the API is well-documented in the code.

7

You can also check example implementations in open source plugins at IntelliJ Platform Explorer.