In visual mode when your selection ends with a newline we show the
cursor at the end of the previous line (not the start of the current
line). We had only been accounting for this if the cursor was on-screen.
Part of
https://linear.app/zed-industries/issue/Z-2750/investigate-performance-of-collaborating-on-large-files-with-inlay
Fixes
https://linear.app/zed-industries/issue/Z-2824/inlay-hints-affect-code-layout-in-multibuffer
We query hints for visible part of the screen, and two parts above and
below the visible range, of the same range (if applicable, we can be on
the edge of the document).
When rapidly typing, we do not care about the invisible range updates,
yet still query a lot of them + rust-analyzer sends /refresh hint
requests shortly after every modification too, forcing us to re-query.
Instead querying both visible and invisible ranges altogether, wait for
visible range query first and wait add a `400ms` delay afterwards before
querying the invisible ranges.
This allows any /refresh requests or rapid typing to avoid 2 extra
requests, cancelling them before they start.
Visible part of the screen is still queried after every change, without
any debouncing.
Release Notes:
- Delay certain inlay hint requests to reduce general LSP server load
This way, only the visible part gets frequently queried on typing (and
hint /refresh requests that follow), with queries for invisible ranges
cancelled eagerly.
Resolves inlay hints on hover, shows hint label parts' tooltips, allows
cmd+click to navigate to the hints' parts with locations,
correspondingly highlight the hints.
Release Notes:
- Support dynamic inlay hints
Often, hint ranges are separated by a single '<` char as in
`Option<Vec<u32>>`. When moving the caret from left to right, avoid
inclusive ranges to faster update the matching hint underline.
Without holding all hints in host's cache, this is impossile.
Currenly, we keep hint caches separate and isolated, so this will not
work when we actually resolve.
