Previously we were always adding the origin coordinate of last item to
the content size, which is incorrect when the list has just one item; in
that case, we should just use the size of that item as the content size
of a list.
Closes #ISSUE
Release Notes:
- N/A
I've been a bit annoyed by the hover divider rule being extremely bright
compared to other divider rules in the UI. This PR updates their color
to use the regular border color from the current theme instead of the
muted (but still pretty bright) text color.
Apologies for the unsolicited PR (and please feel free to close if it
goes against some other plans / designs you already have in place :).
#### Example screenshot before:
<img width="302" alt="Screenshot 2024-10-15 at 23 29 18"
src="https://github.com/user-attachments/assets/7ea22808-8135-4a46-9457-e670225aebaa">
#### Example screenshot after:
<img width="312" alt="Screenshot 2024-10-15 at 23 28 16"
src="https://github.com/user-attachments/assets/63ac0d02-ae6d-4962-84a2-1fdb95519b15">
***
Release Notes:
- Make the divider rule in LSP hovers more muted
* `Open Excerpts` command always opens the locations in the base buffer
* LSP features like document-highlights, go-to-def, and inlay hints work
correctly in branch buffers
* Other LSP features like completions, code actions, and rename are
disabled in branch buffers
Release Notes:
- N/A
After https://github.com/rust-lang/rust-analyzer/pull/18167 and certain
people who type and complete rapidly, it turned out that we have not
waited for `completionItem/resolve` to finish before applying the
completion results.
Release Notes:
- Fixed completion items applied improperly on fast typing
This PR adds the ability to display backgrounds for inlay hints within
the editor.
This is controlled by the new `inlay_hints.show_background` setting.
This setting defaults to `false`.
To enable the setting, add the following to your `settings.json`:
```json
{
"inlay_hints": {
"enabled": true,
"show_background": true
}
}
```
When enabled, the inlay hint backgrounds will use the `hint.background`
color from the theme.
| Disabled | Enabled |
|
--------------------------------------------------------------------------------------------------------------------------------------------------
|
--------------------------------------------------------------------------------------------------------------------------------------------------
|
| <img width="1624" alt="Screenshot 2024-09-17 at 4 21 53 PM"
src="https://github.com/user-attachments/assets/5534d09b-1e22-4c6f-9d82-314796ed7d22">
| <img width="1624" alt="Screenshot 2024-09-17 at 4 21 43 PM"
src="https://github.com/user-attachments/assets/6ec58cde-6115-4db4-be95-97c5f2f54b2d">
|
Related issues:
- #12485
- #17392
Release Notes:
- Added an `inlay_hints.show_background` setting to allow displaying
backgrounds for inlay hints in the editor.
- This setting defaults to `false`.
- If enabled, the inlay hint backgrounds will use the `hint.background`
color from the theme.
Part of https://github.com/zed-industries/zed/issues/8081
To avoid confusion and bugs when converting between various row `u32`'s,
use different types for each.
Further PRs should split `Point` into buffer and multi buffer variants
and make the code more readable.
Release Notes:
- N/A
---------
Co-authored-by: Piotr <piotr@zed.dev>
The DisplayPoint returned from the position map is only valid at the
snapshot in the position map.
Before this change we were erroneously using it to index into the
current version of the buffer.
Release Notes:
- Fixed a panic caused by a race condition in hover.
I ran into this specifically when looking at the documentation of
https://crates.io/crates/wayland-client
Release Notes:
- Fixed a bug where some hover popovers would render `\n` instead of a
new line.
Refs #9647
Fixes https://github.com/zed-industries/zed/issues/9792
This pull request moves the computation of scrollbar markers off the
main thread, to prevent them from grinding the editor to a halt when we
have a lot of them (e.g., when there are lots of search results on a
large file). With these changes we also avoid generating multiple quads
for adjacent markers, thus fixing an issue where we stop drawing other
primitives because we've drawn too many quads in the scrollbar.
Release Notes:
- Improved editor performance when displaying lots of search results,
diagnostics, or symbol highlights in the scrollbar
([#9792](https://github.com/zed-industries/zed/issues/9792)).
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Nathan <nathan@zed.dev>
Closes#5178
Release Notes:
- Added a `file_types` setting that can be used to associate languages
with file names and file extensions. For example, to interpret all `.c`
files as C++, and files called `MyLockFile` as TOML, add the following
to `settings.json`:
```json
{
"file_types": {
"C++": ["c"],
"TOML": ["MyLockFile"]
}
}
```
As with most zed settings, this can be configured on a per-directory
basis by including a local `.zed/settings.json` file in that directory.
---------
Co-authored-by: Marshall <marshall@zed.dev>
See https://zed.dev/channel/gpui-536
Fixes https://github.com/zed-industries/zed/issues/9010
Fixes https://github.com/zed-industries/zed/issues/8883
Fixes https://github.com/zed-industries/zed/issues/8640
Fixes https://github.com/zed-industries/zed/issues/8598
Fixes https://github.com/zed-industries/zed/issues/8579
Fixes https://github.com/zed-industries/zed/issues/8363
Fixes https://github.com/zed-industries/zed/issues/8207
### Problem
After transitioning Zed to GPUI 2, we started noticing that interacting
with the mouse on many UI elements would lead to a pretty annoying
flicker. The main issue with the old approach was that hover state was
calculated based on the previous frame. That is, when computing whether
a given element was hovered in the current frame, we would use
information about the same element in the previous frame.
However, inspecting the previous frame tells us very little about what
should be hovered in the current frame, as elements in the current frame
may have changed significantly.
### Solution
This pull request's main contribution is the introduction of a new
`after_layout` phase when redrawing the window. The key idea is that
we'll give every element a chance to register a hitbox (see
`ElementContext::insert_hitbox`) before painting anything. Then, during
the `paint` phase, elements can determine whether they're the topmost
and draw their hover state accordingly.
We are also removing the ability to give an arbitrary z-index to
elements. Instead, we will follow the much simpler painter's algorithm.
That is, an element that gets painted after will be drawn on top of an
element that got painted earlier. Elements can still escape their
current "stacking context" by using the new `ElementContext::defer_draw`
method (see `Overlay` for an example). Elements drawn using this method
will still be logically considered as being children of their original
parent (for keybinding, focus and cache invalidation purposes) but their
layout and paint passes will be deferred until the currently-drawn
element is done.
With these changes we also reworked geometry batching within the
`Scene`. The new approach uses an AABB tree to determine geometry
occlusion, which allows the GPU to render non-overlapping geometry in
parallel.
### Performance
Performance is slightly better than on `main` even though this new
approach is more correct and we're maintaining an extra data structure
(the AABB tree).
Release Notes:
- Fixed a bug that was causing popovers to flicker.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Thorsten <thorsten@zed.dev>
Prepare for git diff hunk highlights by grouping all inlay highlight
properties into one struct, and removing the dead background highlight
code.
Release Notes:
- N/A
We were seeing panics due to callers assuming they had valid
excerpt_ids, but that cannot easily be guaranteed across await points as
anyone may remove an excerpt.
Release Notes:
- Fixed a panic when hovering in a multibuffer
This practice makes it difficult to locate todo!s in my code when I'm
working. Let's take out the bang if we want to keep doing this.
Release Notes:
- N/A
I think this makes it less chaotic to edit text when the inlay hints are
on.
It's for cases where you're editing to the right side of an inlay hint.
Example:
```rust
for name in names.iter().map(|item| item.len()) {
println!("{:?}", name);
}
```
We display a `usize` inlay hint right next to `name`.
But as soon as you remove that `.` in `names.iter` your cursor jumps
around because the inlay hint has been removed.
With this change we now have a 700ms debounce before we update the inlay
hints.
VS Code seems to have an even longer debounce, I think somewhere around
~1s.
Release Notes:
- Added debouncing to make it easier to edit text when inlay hints are
enabled and to save rendering of inlay hints when scrolling. Both
debounce durations can be configured with `{"inlay_hints":
{"edit_debounce_ms": 700}}` (default) and `{"inlay_hints":
{"scroll_debounce_ms": 50}}`. Set a value to `0` to turn off the
debouncing.
### Before
https://github.com/zed-industries/zed/assets/1185253/3afbe548-dcfb-45a3-ab9f-cce14c04a148
### After
https://github.com/zed-industries/zed/assets/1185253/7ea90e42-bca6-4f6c-995e-83324669ab43
---------
Co-authored-by: Kirill <kirill@zed.dev>
rust analyzer has a tendency to return markdown of the form:
```rust
// <-- note the leading space
blah blah blah
```
This is clearly defectuous, so we used to .trim() the output.
Unfortunately we trim after applying syntax highlighting, so that causes
the output to look goofy.
Fix this by updating the highlighting when we trim.
Piotr Osiewicz
Conrad Irwin
Tilman Roeder
Kirill BulatovandAntonio Scandurra
Max Brunsfeld
Marshall Bowers
Stanislav Alekseev
EphramandConrad Irwin
Nate Butler
Joseph T. Lyons
Mikayla Maki
ethan
Julia