Initial idea of this change was to report the cursor position only when it is visible to protect from cursor position flickering when applications hide it for a moment to do some screen change.
But the problem is that some applications may hide the cursor right from the start, so our UI logic doesn't receive the correct cursor position, so we can show composed text from input methods in the incorrect position.
(cherry picked from commit 6f343aef47a5a9fb5b3fd9d6f5bf7ca7d04f40bf)
IJ-CR-214329
GitOrigin-RevId: ec23dc959c62e6383c8cb5378b4dec3ac5c83541
Two-sided comments (starts on one side, ends on another) should be visible in side-by-side diff on their end side to avoid missing comments and stucking during navigation by comments.
Fixed IJPL-249453
GitOrigin-RevId: 01c24b238c5f37646e5fcd7127af651149d4a268
Use correct comparator for DiscussionIdAndMappedPosition to avoid missing drafts if they are attached to the same line
Fixed IJPL-249453
GitOrigin-RevId: 9a48e9c9b10c9dde4e8db3a0ff47ecd00a5110d2
Use extension point instead of overridable service.
(cherry picked from commit 015c826315a1384a2b95bb32371d72c2e9d58a19)
IJ-CR-210406
GitOrigin-RevId: 2d1153e8f726414d4201d92242047abf5d74a10f
When smart mode activates in IJ Light, the thin-client PortForwardingManager implementation replaces the EEL-based impl. Problem is that these implementations are stateful and can't be replaced in a running terminal session.
So, we can avoid sudden replacement in 2 ways:
1. Cache the manager in a port forwarding session - so, terminal tabs opened before smart mode, will continue using the EEL-based impl.
2. Try to react on new port forwarding manager loading and move the current state to it.
The second is quite complicated, so let's proceed with the first aproach.
(cherry picked from commit 3e28e7f3a3f1cf4071dc5f5572c3001682b584c0)
IJ-CR-210406
GitOrigin-RevId: e9a7748c8f78c3fe8aadf8693b4489c2502fea37
It is not required in this case, and also it is not possible - we don't have a connection to the backend to get the settings.
(cherry picked from commit 58911a63531bcbf6dd8164ebfc76efb70e1e4506)
IJ-CR-210406
GitOrigin-RevId: 80d94510d656faf8524da083f33702c9939c3a10
PY-89838 Python Packages Tool Window redesign Remove unused packaging-related classes and redesign PPTW, Interpreter settings and Repository settings
PY-88291 (WIP): Move hatch and poetry additional data to hatch and poetry modules to make it acessible outside of `community.impl`
PY-88291 (WIP): Move `UvAdditionalData` to uv module to make it acessible outside of `community.impl`
GitOrigin-RevId: bf795344c918e44208f7c02f2eb58246cf9f578b
When a generic decorator's expected parameter type is a free type variable, bind it by matching the decorator's return type against the type the surrounding decorators expect of its result, flowing the constraint inward through the chain
(cherry picked from commit 6afb2e27cd84fe39d5f7fe8addf998a7c9fa422f)
GitOrigin-RevId: dc3214b4dd6e77cdc96f9f589626ef8558015fea
A generic descriptor used as a decorator did not bind its type parameter from the decorated function, so instance access yielded the unbound type variable (or the wrapped function) instead of the value type.
(cherry picked from commit bea29363527746251dc39a8f0d430c468796bd9a)
GitOrigin-RevId: a361e87ab1f3c0ca57f745ce17aee55d979c36e3
A type variable used both as a value (`T`) and as a class object (`type[T]`) was collected twice — in instance and definition form — so a parameterized generic type alias such as `Union[Role[T], type[T]]` appeared to have two type parameters. Subscripting it with a single argument mapped the surplus parameter to Any, which collapsed the `type[T]` arm and left the type variable unbound: e.g. `select(Model)` was inferred as `Select[tuple[Any]]` instead of `Select[tuple[Model]]`, losing element types (and completion) on query results.
Normalize type variables to their instance form when counting a generic type's parameters in PyTypeChecker.parameterizeType, so the same variable is counted once.
(cherry picked from commit 5ae8e727eef7168caafa269dc5fd64c0a38f36f8)
GitOrigin-RevId: f7c58e89e561d1cbc70bee22821b7e62272fd545
A parameterized generic type alias whose value is `type[T]` (e.g. `Alias = type[T]`) lost the class-object wrapper during type-variable substitution: `Alias[int]` was inferred as `int` instead of `type[int]`, and call inference through such an alias bound the type variable to the whole `type[...]`.
`type[T]` is represented as a definition-form type variable, but PyTypeChecker.substitute returned the matched substitution in instance form. Re-apply the class-object form when the substituted type variable is a definition.
(cherry picked from commit 980090804b53aa52f6688912927e9a38208b7884)
GitOrigin-RevId: 96874455827baba6fdbafea06d7cdb87a018898a
It is a better solution that doesn't use internal path translations like `ijentToLocal` - EelPath is expected to contain the original path with correct characters.
(cherry picked from commit a73b34075457f3f6dee27469535f24e19252d8f5)
IJ-CR-213436
GitOrigin-RevId: a14cdf91e9cae7bffa7e6ab861d8a6190302a426
The problem was in the incorrect socket symlink format we receive from the Linux host on Windows. The roots go deep into details how Unix paths are represented on Windows via EEL API: IJPL-213371.
Fix it by mapping the incorrect file path back to the Linux representation.
(cherry picked from commit 7411b02732b0aec6d6a5890ebb7e307024ec24a9)
IJ-CR-213436
GitOrigin-RevId: a762373d03c956ef970de00af406f4df6ebacb20
From user reports I observe that `configureStartupOptions` returns a fake frontend project path as a working directory, so it triggers our safeguard and fails the terminal startup.
The working directory is obtained in `getDefaultStartingDirectory`.
There are can be 3 options why it can happen:
1. User configured the frontend project path in the settings (very unlikely)
2. `getDefaultStartingDirectory` returns frontend project path because of default path customizers (unlikely, we have none customizers that can do that and there are no external plugins with customizers in reports)
3. `toExistentNioDirectory` returns null for the remote project path - very strange and hard to understand why.
Anyway, it looks like that the branch with `guessProjectDir` may execute in some cases - and it would be definitely wrong in RemDev. Let's use the correct way for obtaining the project path. And use correct way for obtaining user home as a fallback.
(cherry picked from commit aceb27d152f5e6f087df59e5d33fb20339b07886)
IJ-CR-213804
GitOrigin-RevId: 7e1e7e51cf5701c1db8ebc1a13763baa51ecde47
Avoid reordering plugins across `build/plugins` and `pluginManagement` when configuring Kotlin in Maven projects. The previous logic assumed the reordered plugin would always be resolved from `build/plugins`, which caused a NoSuchElementException for root POMs that keep javac settings in `pluginManagement`.
(cherry picked from commit 431b37eece386b8c85a7a04cfd2a5cc139a4c355)
IJ-CR-213466
GitOrigin-RevId: 631849e34a1b0907ac680566bd925378447fae53
FUS Updater
Aydar Mukhametzyanov
TeamCity
TeamCity
Andrey Cherkasov
Konstantin Hudyakov
Alexander Bubenchikov
Valeria Golovina
Konstantin Bulenkov
Ilya Kazakevich
natalia.ponomareva
Daniil Kalinin
Vlad Koshkin
Ilia Permiashkin
Nikolay Chashnikov
Ekaterina Berezhko
Vladimir Parfinenko
Bartosz Janusz
alexey.afanasiev
Roman Shevchenko
David Lysenko
Marina Mădăraș