Deprecated EditorWindow.INITIAL_INDEX_KEY with replacement marked as @ApiStatus.Internal
已回答
Opening file with specific tab index using INITIAL_INDEX_KEY is deprecated:
/**
* @deprecated Use file opening methods taking {@link FileEditorOpenOptions} instead
* and pass the index through {@link FileEditorOpenOptions#withIndex(int)}.
*/
@Deprecated
public static final Key<Integer> INITIAL_INDEX_KEY = Key.create("initial editor index");
Meanwhile, FileEditorOpenOptions is marked Internal:
@ApiStatus.Internal
data class FileEditorOpenOptions(
var selectAsCurrent: Boolean = true,
Any suggestions?
请先登录再写评论。
Hi Vladimir,
Could you please clarify the issue? I can’t find the
INITIAL_INDEX_KEY
neither incom.intellij.openapi.fileEditor.impl.EditorWindow
norcom.intellij.injected.editor.EditorWindow
(I also skimmed a few commits). Which class do you mean, and what platform version?In my plugin, I have an option to reopen editors when file type changes. Official JetBrains policy was that file type changes do not reload editors, keeping the file type as it was when the file was opened. So, I implemented my own reopen editors, preserving the tab order.
I am compiling against 2021.3, it is the
com.intellij.openapi.fileEditor.impl.EditorWindow
class.Meanwhile,
FileEditorOpenOptions
:Hi
> Official JetBrains policy was that file type changes do not reload editors, keeping the file type as it was when the file was opened
I'm sorry, this is still the case.
I'm against opening FileEditorOpenOptions, because this subsystem is being actively re-designed.
I see two options, though:
1. We can consider providing an API to trigger the reopening of all existing editors.
2. We can re-consider re-opening affected tabs on file type change.
Can you describe your use-case in details? Why do you need to re-open right away?
I feel your dilemma, but the view from the other side is that what you don't officially provide, will wind up using internal, brittle solution or hacks (reflection and setAccessible()) that are more pain for everyone involved.
In my plugin, there is an option to associate HTML files with the plugin's split editor with an HTML preview pane. When the plugin detects that an editor file mismatches with what the plugin's EditorProvider.acceptFile() thinks about the file, then my plugin will reload those tabs so they can be associated with the correct editor handling the type.
I personally like the use of configuration like the INITIAL_INDEX_KEY with putUserData because it does not create class, interface or method signature dependencies in dependent code. Whoever needs it, uses it, everyone else is oblivious. I can also easily use reflection to test if the field is available and provide my own dummy, when it is not, that way your implementation will ignore it, but my code will work without modification.
However, it can be more error prone, but then I have not encountered an error free programming model, yet.
Have there been a lot of bug reports related to use of the old implementation? Just curious if it is churning because it is ugly or it creates real issues in maintenance?
BTW, reloading all editors tabs, depending on how many are open, can create a jarring visual effect. That is why I dove into the innards with my own implementation.
How about a method taking a Predicate<VirtualFile> so you only reload only what needs to be reloaded?
If it helps, the method I use is here, it gets an array of files whose editor association changed. The INITIAL_INDEX_KEY is my wrapper delegating to EditorWindow.INITIAL_INDEX_KEY if one is available or do nothing if it is not.