Lately, I've been finding Rust-analyzer unusably slow when editing large
files (like `editor_tests.rs`, or `integration_tests.rs`). When I
profile the Rust-analyzer process, I see that it sometimes saturates up
to 10 cores processing a queue of code actions requests.
Additionally, sometimes when collaborating on large files like these, we
see long delays in propagating buffer operations. I'm still not sure why
this is happening, but whenever I look at the server logs in Datadog, I
see that there are remote `CodeActions` and `DocumentHighlights`
messages being processed that take upwards of 30 seconds. I think what
may be happening is that many such requests are resolving at once, and
the responses are taking up too much of the host's bandwidth.
I think that both of these problems are caused by us sending way too
many code action and document highlight requests to rust-analyzer. This
PR adds a simple debounce between changing selections and making these
requests.
From my local testing, this debounce makes Rust-analyzer *much* more
responsive when moving the cursor around a large file like
`editor_tests.rs`.
Omit in buffers with one or zero running language servers with the
capability to provide completions
Co-Authored-By: Antonio Scandurra <antonio@zed.dev>
* `script/bundle -l` will only build for the current architecture and
skip DMG creation. It will also copy to `/Applications`.
* `script/bundle -l "My Bundle"` will name the bundle after your
provided name.
* Passing `-f` will overwrite. Passing `-o` will also open the
application.
Follow-up of https://github.com/zed-industries/zed/pull/2899
Terminal has to accept `[` and `]` as valid word parts, due to
`[slug].tsx` being a valid file name.
Yet, terminal has to exclude these to match paths in strings like
`[/some/path/[slug].tsx]`.
Release Notes:
- N/A
Terminal has to accept `[` and `]` as valid word parts, due to
`[slug].tsx` being a valid file name.
Yet, terminal has to exclude these to match paths in strings like
`[/some/path/[slug].tsx]`.
* Use a single row, instead of centering the search bar within a double-row toolbar.
* Search query controls on the left, navigation on the right
* Semantic is the final mode, for greater stability between buffer and project search.
* Prevent query editor from moving when toggling path filters
Rather than adding primary toolbar item that renders as empty,
don't add an item at all. This prevents spurious spacing from
being added after other primary toolbar items.
When you pass -l, we build for the local architecture only and copy the
resulting app bundle to /Applications. You can provide a bundle name as
an optional argument.
Fresh off the press, memchr 2.6.0 adds vector search routines for
aarch64. That directly improves our search performance for both text and
regex searches. Per BurntSushi's claims, the simple string searches in
ripgrep got ~2 times faster (more details available in
https://github.com/BurntSushi/memchr/pull/129).
Release Notes:
- N/A
See Linear description for the full explanation of the issue. This PR is
mostly a mechanical change, except for the one case where we do pass in
an explicit `next_id` instead of `model_id` in project.rs.
Release Notes:
- Fixed a bug where some results were not reported in project search in
presence of unnamed buffers.
Deals with https://github.com/zed-industries/community/issues/1865
` ./src/pages/[[...slug]].tsx` is a valid file path in macOs and Linux,
and should be available for cmd-hover-click in terminal.
Release Notes:
- Allow `[` and `]` symbols in terminal links
Better handle edge cases around cmd+hover around inlays:
* distinguish between same text anchors' trigger: inlay and text
triggers can have the same anchor, but are different
* forbid cmd+click on inlay that has no label part with location
selected
* properly omit throttled inlays that are outside of the visible range
Release Notes:
- N/A
Nate Butler
Max Brunsfeld
Antonio Scandurra
Nathan Sobo
JuliaandAntonio Scandurra
Piotr Osiewicz
Kirill Bulatov
