In Rider we want to pass ReSharper settings layers to UI-parts like combobox for choosing default dictionary to save words.
GitOrigin-RevId: b6b395d0108f2f1142fc1ab3656d3493c5b9be9c
Some backend-driven languages in Rider don't have detailed frontend lexer/parser, so the only node visible to spellchecker will be root PsiFile. We pass range-scope information from backend, and then rider's spell checking strategy will handle it itself.
GitOrigin-RevId: b97c9eaaed30d6a0e09d69b13cf4cd5ad1b5d364
This allows for resolving bundles with a custom locale, especially in cases where the plugin context is not initialized yet.
GitOrigin-RevId: 252e15e870d1ac6f573f94a6ffe6f524c25d4074
Just for internal testing at this point. It's unusable as it is,
because it spends too much time collecting the paths to expand,
and while it's doing that, nothing visible happens, which leads
to very poor UX.
GitOrigin-RevId: e6db4329984fe504677cd596b6b817794fd3dc1b
Now that we have a separate property for external decorator bounds,
implement it for both decorators to account for invisible insets.
As there seems to be no API for getting those invisible insets,
we use guesswork: the top inset is usually the window header,
and it's visible; the other insets are usually invisible drag zones.
Insets aren't available until the window is connected to an actual display
(the peer is created), so the new property will work incorrectly before
the window is shown for the first time, but thankfully we already have
a helper class to fix the insets after the window is shown, so it works
as expected, even though it's still a dirty hack and not a proper fix.
GitOrigin-RevId: efd75de13d070a6873bda05898803cc533259194
We're going to implement more complicated bounds computation,
and they will no longer match what getBounds() returns,
so (ab)using the property inherited from Java isn't going to work
anymore. We need our own.
Use the new property wherever possible in ToolWindowManagerImpl.
GitOrigin-RevId: cd6deb14de4d629fa63d7b3e8b6810bc05a48558
This action delegates to RestoreNamedLayoutActionGroup,
which already sets its update thread to BGT, but
it wasn't set for the delegating action itself, which is simply
a mistake.
GitOrigin-RevId: ab5f117eed45651096768663d3b18188b53c224c
Likely the exception happens because something is invalidated or disposed.
We can safely ignore nulls here, the worst that can happen is that some
element won't be re-selected properly, which is still much better than
an exception being thrown, and at least other, still valid, elements
will be re-selected.
GitOrigin-RevId: ce9cd345dd96175e3f53db249d1e3a9725c31efc
Its implementations are almost always either:
- return a constant;
- return a string from a message bundle;
- delegate to some getTitle() which does one of the above.
However, there are a few cases where toString() here involves
some BGT stuff. The most notable one is
com.intellij.ide.impl.ProjectViewSelectInExplorerTarget.toString
which does some FS operation to detect what's the file manager
should be called (e.g. Explorer, Finder, etc.).
So let's move it into a BGT and only do the UI fallback part
(replace the tool window ID with its title) on the EDT.
GitOrigin-RevId: 82aa4d7618e33f73ccefa444a4349e54576fc18b
+ `-Dvfs.health-check.wrap-in-read-action=false` to disable
(roll back to previous)
+ Main part of VFSHealthCheck wrapped in ReadAction. Since VFS modifications are done under WA, checking consistency without RA is generally incorrect, because the checker could see intermediate inconsistent results.
GitOrigin-RevId: 7010571603cc904ae7a1f2b4e11f0e808bdbdeb4
2. add restart after installing/copying plugins (for consistency) (related to IDEA-336392 New Import Settings: IDE proceeds importing after it's cancelled)
GitOrigin-RevId: 6d9dc3910af45f8a99f5a2a95c8f7ff90863ae69
