How to "close & reopen" an editor while preserving its position in split panes?

Created December 13, 2018 19:41

Sounds a bit weird but the use case is real. The IDE does not close and re-open a file when its type is changed.

My plugin provides a custom editor for Markdown files. The IDE will use the right editor provider when the file is opened. However, if the file is already open then changing the file type will not create a new editor so the custom editor is not used. For example, a user sets the file to plain-text, opens it, then changes the type back to Markdown.

They see markdown syntax highlighting but not the toolbar or preview provided by the custom editor.

Now I have a partial solution by detecting these out of sync conditions and using FileEditorManager to close the file and then open it again. It does solve the problem except if the file was open in multiple editors and in different split panes. then all editors will be closed and only one will re-open in one of the split panes.

Ideally, I would like to re-open each editor for the given file and have the editor location not change. I figured it should be possible to open a new editor next to the errant editor and then close the errant one. Proceeding with all editors for the file.

Is there an easy way to do this easily or will it involve some hackery with the API?

BTW, I noticed the same issue with Designer forms. Switching a form to plain-text and back while the file is open does not reload the editor.

9 comments

Dmitry Batrak

Created December 17, 2018 08:25

I don't think there's an easy way to achieve this currently. It's worth to create a ticket for this in YouTrack.

Vladimir Schneider

Created December 17, 2018 15:26

Thank you Dmitry, it is as I thought.

I will open a YouTrack issue but before that I will put together a solution that works for the plugin since it supports versions 2016.3 or later. Having the problem solved in 2019.1 or later will not help users of previous versions. Occasionally, I still get bug reports for users on version 15 of the IDE.

Once I have a solution, I can open an issue with the solution as an example. Anything to help shorten the implementation time. I am certain my solution will not be optimal but having a starting point is better than nothing.

Vladimir Schneider

Created December 17, 2018 18:33

It was a lot easier than I feared.

The implementation does not change the editor tab position, pinned state and splits. I suspect there is some synchronization issues because I notice a delay while some of the editors are being reopened and the update of the UI. Feels like it takes longer than it should but it does the job with the available API.

private fun reopenFileEditors(files: Array<out VirtualFile>) {
    val fileEditorManager = FileEditorManagerEx.getInstance(project) as FileEditorManagerEx
    val windows = fileEditorManager.windows
    val dummyVirtualFile: VirtualFile? by lazy { LightVirtualFile("dummy.txt", "\n") }

    for (window in windows) {
        val focusedEditor = window.selectedEditor
        val editors = window.editors

        for (file in files) {
            val editorIndex = editors.indexOfFirst { it.file == file }
            if (editorIndex == -1) continue
            
            val fileEditor = editors[editorIndex]
            val pinned = window.isFilePinned(file)

            // may need to add a dummy file if there is only one tab so that when we close the file the tab stays open
            val dummy: VirtualFile? = if (window.tabCount == 1) dummyVirtualFile else null

            if (dummy != null) fileEditorManager.openFileWithProviders(dummy, false, window)

            file.putUserData(EditorWindow.INITIAL_INDEX_KEY, editorIndex)
            window.closeFile(file, true, false)
            fileEditorManager.openFileWithProviders(file, false, window)
            
            if (dummy != null) window.closeFile(dummy)

            if (pinned) window.setFilePinned(file, true)
            
            // clear the index key so it does not keep opening at that tab index by accident
            file.putUserData(EditorWindow.INITIAL_INDEX_KEY, null)
        }

        // restore focused tab for the window
        window.setSelectedEditor(focusedEditor, false)
    }
}

Vladimir Schneider

Created December 17, 2018 22:15

Dmitry, on a somewhat related issue.

In 2019.1 built from intellij-community master, updated this morning, I can switch a markdown file to plain text but the editor highlighting remains to be markdown. If I close and reopen the project the syntax highlighting is corrected to plain text.

If I change the file to markdown and then back to plain text then it will remain markdown syntax highlighting until the project is closed.

I am not getting this issue when I am debugging the plugin or in 2018 or earlier. I also do not remember having this issue until recently.

For the test I disabled all the editor reloading and updating that I added recently and I am still getting this strange caching behaviour.

Dmitry Batrak

Created December 18, 2018 09:49

Lexer-based highlighter seems to be updated as previously. But (at least in case of built-in support) Markdown highlighting is not produced by lexer, but via asynchronous mechanism ('daemon'-based). I don't know why did it stop refreshing unfortunately, it's not my area of expertise. I'll ask someone else to check.

Vladimir Schneider

Created December 18, 2018 12:18

Thanks Dmitry.

What is strange is that this behaviour does not show up when debugging the plugin, so I cannot use the debugger to figure it out.

I will do more snooping around and instrument the IDE editor and highlighter related code to log changes so I can be sure it is not something I am doing before opening an issue on YouTrack.

Vladimir Schneider

Created December 18, 2018 13:53

Dmitry, the issue is not with the highlighter but with external annotator highlights.

When the file type is switched to Plain Text external annotation highlighters are not cleared from the editor (except when under debug) for some reason. So it appears as if syntax highlighting is being done but in fact it is only the uncleared highlighters continuing being applied.

If I modify the text no syntax highlighting appears so it is left-over highlighters from external annotation phase.

Since the file type is now different my external annotator is not called (which is expected) so the old highlights are not cleared.

Dmitry Batrak

Created December 18, 2018 14:37

Right, that was what I meant. Sorry if I was ambiguous. Editor highlighter (usually lexer-based) is updated as expected, but range highlighters, generated by DaemonCodeAnalyzer (including the ones created by external annotators) are not recalculated.

Vladimir Schneider

Created December 18, 2018 15:02

I will open a YouTrack issue for this. Seems like a bug. External annotation highlights no longer apply because of the file type change and should be cleared.

Also, behaviour under debugger is different which makes it a PITA to figure out. I can see in my traces that under debug the external tool pass is invoked and sets highlighters to empty array but when not under debugger it is never invoked so highlights remain.

Please sign in to leave a comment.