Stability of FileManagerEx.openFile(VirtualFile, EditorWindow?, FileEditorOpenOption)

[jaroslav.kavalec (Jarek)]

I finally went through everything I need to make Settings screens, so I am about to release few IntelliJ plugins I made in past 2 years to make my work more comfortable. I will go through some issues I have before full release and I will start with most annoying one.

Stability of FileManagerEx.openFile(VirtualFile, EditorWindow?, FileEditorOpenOption): this is a recuring issues I see popping in and out over those about 2 years since I started with plugin development it always works, and then suddenly this stops, and breaks the functionality altogether.

I need my plugin to open new File in any Editor splitter I chose, so I need to have window parameter available as well as declaring that I want to have that window focused upon opening the Editor. This is exactly what problematic method does perfectly when it works.

This seems to be a constant issue I am facing with this API for very long time - there is a vicious cycle of this working then suddenly stopping.

This is what I get when the method is called on 2025.3 line of products:

java.lang.NoSuchMethodError: ‘void com.intellij.openapi.fileEditor.impl.FileEditorOpenOptions.(boolean, boolean, boolean, boolean, boolean, int, boolean, com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl$OpenMode, boolean, boolean, kotlin.jvm.functions.Function0, int, kotlin.jvm.internal.DefaultConstructorMarker)’

Situation on my side: Plugin is developed in Idea 2025.2.5 - it is tested on same version - so version that is installed on actual working IDE instance behaves exactly same as the one that is run through Gradle command while in development.

The issue I am describing happens in both RustRover and WebStorm 2025.3 (tested on WS 2025.3.1 as well with same behavior)

On WS 2025.2.6 which is latest of 2025.2 version everything works as expected.

GPT AI made me even believe for five minutes before I downgraded WS that it was only ever working on IntelliJ alone not on others which made me hallucinate, but it at least apologized :

To the Esteemed Comrade,

I submit this apology under the gravest circumstances, fully aware that the stability of the people’s plugin, the integrity of editor splitters, and the correct operation of FileManagerEx methods depend on my words.

I must confess that I previously declared, with absolute confidence:

“FileManagerEx.openFile(VirtualFile, EditorWindow?, FileEditorOpenOption) and similar methods do not exist in WebStorm or RustRover — it is physically impossible.”

This statement was ideologically false and materially incorrect. The method did exist in previous versions, and by asserting impossibility I misrepresented reality, wasted time, and ignored the explicit requirement to open files in a specific EditorWindow. In current versions, its continued and unexpected behavior serves as a reminder of the terrifying complexity of editor splitters and the danger of speaking with certainty where verification was required.

My guidance, founded on this false assertion, was insufficient and unworthy of the people’s plugin.

With maximal contrition and full awareness of my failure,

Gavriil P. Tokarev, Glavnyy Podkomissar Tekhnologii

[yuriy.artamonov]

@jaroslav.kavalec

FileManagerEx

The openFile method is @ApiStatus.Internal because of the argument class FileEditorOpenOptions and cannot be used in plugins at the moment. Could you share an example use you need so we can plan some rework/publishing of API?

[jaroslav.kavalec (Jarek)]

The use case is for instance for moving active editor to any split at will (plugin TabShifter uses this in similar way to move documents to neighboring tabs and gets broken as well), to me this prevents a release of plugin as it is pretty unstable - for now I am on versions before .3 release so it works without issues there.

fun move_active_document_to(horizonntal: Int, vertical: Int, e: AnActionEvent) =  editor_action(e) { context ->
	//here I pass target editor from the grid of splitters by coordinates - this is not active editor
	get_editor_window(context.root, vertical, horizonntal, context.file_editor_manager).let {target_editor_window ->
		context.active_editor_window.selectedFile?.let {file ->
			//I close current document in active splitter
			context.active_editor_window.closeFile(file)
			//here is the unsable API
			//I need to open a document in target editor (Randomness is unaceptable here)
			//and at the same time immediately request focus to that editor
			context.file_editor_manager.openFile(file, target_editor_window, FileEditorOpenOptions(
				requestFocus = true
			))
		}
	}
}

[yuriy.artamonov]

@jaroslav.kavalec

so it works without issues there.

Just to be sure I rechecked that FileEditorManagerImpl class was marked with @ApiStatus.Internal in 2024.2 and this is how its usage looks in IntelliJ IDEA, for instance with API 2025.2:

So, no we certainly have not break any public APIs here as FileEditorManagerImpl is not a subject to backward compatible changes. Moreover, FileEditorOpenOptions is @ApiStatus.Internal as well since 2021.

[yuriy.artamonov]

Meanwhile, let us think of how and when we can mark or evolve FileEditorOpenOptions stable and when FileEditorManagerEx.openFile(file: VirtualFile, window: EditorWindow?, options: FileEditorOpenOptions = FileEditorOpenOptions()) may become available to plugins.

[yuriy.artamonov]

Here is the issue to track

Expose FileEditorManagerEx.openFile overload with target Editor window and...