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

Apply a rate limiter to hints scrolling, properly invalidate hint task
cached ranges, properly react to multibuffer events, properly highlight
hints and introduce basic debug logging for hints.

Release Notes:

- N/A

Miltibuffer emits edit events even if it only got an excerpt
added/removed/etc.
Separate buffer edits and trigger hint invalidation refresh for them
only, also trigger hint new lines refresh on excerpt addition events.

This PR adds the wiring to both the server and the client for sending
and receiving individual feature flags, as well as a client side API for
convenient access to these feature flags.

Release Notes:

- N/A

* https://github.com/zed-industries/zed/pull/2891

Fixes ranges pointing at incorrect positions inside multi-codepoint
characters

* https://github.com/zed-industries/zed/pull/2890

Defers hint links' document URL resolution into buffer up until the
hover & cmd-click is made by the user.

Release Notes:

- N/A

This fixes a bug where text moved up and down by one pixel in the buffer
search query editor, while typing.

Release  notes:
* Fixed a bug where editors didn't auto-scroll when typing if all
cursors could not fit within the viewport.

This is the first batch of improvements to current project search. There
are few things we can do better still, but I want to get this out in
next Preview.
Most of the slowness at this point seems to stem from updating UI too
often.

Release Notes:
- Improved project search by making it report results sooner.

---------

Co-authored-by: Julia Risley <julia@zed.dev>

* Scroll to the newest cursor if all cursors can't fit in the viewport.
* Refuse to layout an editor less tall than one line height.

Co-authored-by: Nathan <nathan@zed.dev>

Use word_characters to feed completion trigger characters as well and
also recognize kebab as a potential sub-word splitter. This is fine for
non-kebab-case languages because we'd only ever attempt to split a word
with a kebab in it in language scopes which are kebab-cased

Co-Authored-By: Max Brunsfeld <max@zed.dev>

Before this change up and down were in display co-ordinates, after this
change they are in fold coordinates (which matches the vim behaviour).

To make this work without causing usabliity problems, a bunch of extra
keyboard shortcuts now work:

- vim: `z {o,c}` to open,close a fold
- vim: `z f` to fold current visual selection
- vim: `g {j,k,up,down}` to move up/down a display line
- vim: `g {0,^,$,home,end}` to get to start/end of a display line

Fixes: zed-industries/community#1562

- Add relative_line_mode
- vim change for wrapped lines

Release Notes:

- Add a `relative_line_numbers` setting
([#988](https://github.com/zed-industries/community/issues/998)).

This isn't ready to go - I'm opening a PR to ask for some advice. When
activating a python virtual environment, the typical command used is
`source path_to_venv/bin/activate`. The problem is, the activatate
script isn't portable to all shells, so some additional scripts are
bundled in the env, for example, `activate.fish`. We don't have a good
way of knowing what shell we are in, in order to know what script to
run.

Julia gave the alternative of simply activating the virtual environment
while in the zsh context, before the user's custom shell is launched,
which I think does work, but because we activate the virtual environment
before we launch the custom shell, the shell isn't really aware that we
are in the virtual environment and it fails to display the information
in the prompt that is typically shown after activating.

Is there a clean way for us to know for a fact what shell is being ran,
so we know what script to run?

Check out the code comments below for more context.

---


https://github.com/zed-industries/zed/assets/19867440/ddb76aaa-152b-4c93-a513-3cd580b7c40f

I've used Zed to write Python scripts, but working on an actual project
has really magnified where Python dev is falling short. A huge
quality-of-life thing we can do is provide a setting to automaticaly
search for and activate virtual environments when found, when terminals
are created. Manually starting these up in every terminal instance is
such a drag.

A few quirks:
- We don't have a way of knowing if the prompt is ready before we try
run the command, which means we see the text inserted at the top of the
terminal and on the prompt - I dont think this should be a blocker
though.
- If a user has multiple python projects with mutliple virtual
environments, we only detect and activate the first one, since can't
really make any assumptions about which one to activate. I dont think
this should be a blocker either, as I think most users will have a
single project open in Zed.

Release Notes:

- Added a `detect_venv` setting for the terminal. When configured, the
Zed terminal will automatically activate Python virtual environments on
terminal creation.

Co-Authored-By: Mikayla Maki <mikayla.c.maki@gmail.com>

Release Notes:

- vim: fix goal preservation of visual block selections
([#1950](https://github.com/zed-industries/community/issues/1950)).

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.

Co-Authored-By: joseph@zed.dev