Turns out we still get FocusOut and UnmapNotify events after the window
has been destroyed, which resulted in error messages popping up because
we can't find the window anymore that we want to mark as unfocused.



Release Notes:

- N/A

Fixes most vim tests on linux (and a few editor ones) by loading Zed
Mono
instead of relying on the system fallback stack.

Release Notes:

- N/A

Also, as a drive-by, we're fixing up/down not working in inline
assistant editor.

Release Notes:

- N/A

This PR adds support for [linked editing of
ranges](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_linkedEditingRange),
which in short means that editing one part of a file can now change
related parts in that same file. Think of automatically renaming
HTML/TSX closing tags when the opening one is changed.
TODO:
- [x] proto changes
- [x] Allow disabling linked editing ranges on a per language basis.

Fixes #4535 

Release Notes:
- Added support for linked editing ranges LSP request. Editing opening
tags in HTML/TSX files (with vtsls) performs the same edit on the
closing tag as well (and vice versa). It can be turned off on a language-by-language basis with the following setting:
```
  "languages": {
    "HTML": {
      "linked_edits": true
    },
  }
```

---------

Co-authored-by: Bennet <bennet@zed.dev>

This pull request introduces a new diff mechanism that helps users
understand exactly which lines were changed by the LLM.

Release Notes:

- N/A

I noticed that when I use my mouse wheel, we get a ton of the
`XkbStateNotify` events, but the modifiers don't change, so we add a ton
of useless input events for the window.

Release Notes:

- N/A

Release Notes:

- N/A

Release Notes:

- vim: Fixed `f`/`t` etc. for keys that require IME (#12522)

Release Notes:

- N/A

---------

Co-authored-by: Max <max@zed.dev>

Release Notes:

- N/A

## Description

When using rust-lld it's possible to get a `STATUS_ACCESS_VIOLATION`
error at compile time. I added a bit of information about it in the
build guide for windows to recommend using a different linker when
building `zed`.

---------

Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>

Release Notes:

- N/A

This PR improves the `/fetch` command with better support for URLs that
return JSON content.

JSON response bodies will now be pretty-printed and placed within a
Markdown code block:

<img width="690" alt="Screenshot 2024-06-10 at 3 39 52 PM"
src="https://github.com/zed-industries/zed/assets/1486634/4a7c1cb7-9f5b-4a63-9e8e-5168bf9a6625">

Release Notes:

- Improved the handling of JSON response bodies in the `/fetch` command
in the Assistant.

This PR removes the `color` crate, as it was not used anywhere.

We had added this experimentally, but right now its existence is just a
source of confusion.

Release Notes:

- N/A

This PR adds a missing LICENSE file to the recently-extracted `proto`
crate.

Release Notes:

- N/A

Release Notes:

- N/A

Release Notes:

- N/A

---------

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

This PR adjusts the extension download counts to be displayed using
thousands separators.

Release Notes:

- Adjusted extension download counts to display with thousands
separators (e.g., `1,000,000`).

This PR adds a `/now` command to the Assistant for indicating the
current date and time to the model.

Release Notes:

- Added `/now` command to the Assistant for getting the current date and
time.

Hi, this pull request superseeds the
https://github.com/zed-industries/zed/pull/12624
and removes queries for runnables from `outline.scm`. This pull request
has couple things to mention:

- Removed task for running tests with `minitest` as I think it's not
reliable in its state because, AFAIK, the only way to run `minitest`
with the specific line, i.e. `bundle exec rake test
spec/models/some_model.rb:12` is to use it with Rails. The support for
`minitest` is still there and users can add their own task, for
instance, when they use `minitest` in Rails to get support for running
tests:

  ```json
  {
    "label": "test $ZED_RELATIVE_FILE:$ZED_ROW",
    "command": "./bin/rails",
    "args": ["test", "\"$ZED_RELATIVE_FILE:$ZED_ROW\""],
    "tags": ["minitest-test"]
  }
  ```

**Question:** Perhaps that should be mentioned in the Ruby extension
documentation?

- Adjusted runnables queries to work without `ZED_SYMBOL`.

Release Notes:

- N/A

This helps with the problem of keyboard input feeling laggy when the
event loop is under load.

What would previously happen is:

- N events from X11 arrive
- N events get forwarded to XIM
- N events are handled in N iterations of the event loop (sadly, yes: we
only seem to be getting back one `ClientMessage` per poll from XCB
connection)
- Each event is pushed into the channel
- N event loop iterations are needed to get the events off the channel
and handle them

With this change, we get rid of the last 2 steps: instead of pushing the
event onto a channel, we store it on the XIM handler itself, and then
work it off synchronously.

Usually one shouldn't block the event loop, but I think in this case -
user input! - it's better to handle the events directly instead of
re-enqueuing them again in a channel, where they can accumulate and need
multiple iterations of the loop to be worked off.

This does *not* fix the problem of input feeling choppy/slower when the
system is under load, but it makes the behavior now feel exactly the
same as when XIM is disabled.

I also think the code is easier to understand since it's more
straightforward.

Release Notes:

- N/A

This change ensures that the event loop prioritizes enqueueing another
render or handling user input over executing runnables.

It's a subtle change as a result of a week of digging into performance
on X11. It's also not perfect: ideally we'd get rid of the intermediate
channel here and had more control over when and how we run runnables vs.
X11 events, but I think short of rewriting how we use an event loop,
this is good cost/benefit change.

To illustrate:

Before this change, it was possible to block the app from rendering for
a long time by just creating a ton of futures that were executed on the
"main" thread (we don't have a "main" thread on Linux, but we have a
single thread in which we run the event loop).

That was relatively easy to reproduce by opening the `zed` repository
and starting `rust-analyzer`: at some point `rust-analyzer` sends us so
many notifications, that are all handled in futures, that the event loop
is busy just working off the runnables, never getting to the events that
X11 sends us or our own timer to re-enqueue another render.

When you put print statements into the code to show when which event was
handled, you'd see something like this **before this change**:

```
[ ... hundreds of runnable.run() ... ]
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 56.942049ms
X11 event
new render tick timer. lag: 9.668µs
X11 event
new render tick timer. lag: 9.955µs
X11 event
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 12.462µs
X11 event
new render tick timer. lag: 14.868µs
X11 event
new render tick timer. lag: 11.234µs
X11 event
new render tick timer. lag: 11.681µs
X11 event
new render tick timer. lag: 13.926µs
X11 event
```

Note the `lag: 56ms`: that's the difference between when we wanted to
execute the callback that enqueues another render and when it ran.

Longer lags are possible, this is just the first one I grabbed from the
logs.

Now, compare this with the logs **after this change**:

```
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 36.051µs
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
X11 event
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
```

In-between many `runnable.run()` we'll always handle events.

So, in essence, what this change does is to introduce 2 priorities into
the X11 event queue:

- high: X11 events (user events, render events, ...), render tick, XIM
events, ...
- low: all async rust code

I've tested this with a debug build and release build and I think the
app now feels more responsive. It doesn't feel perfect still, especially
in the slow debug builds, but I couldn't observe 10s lockups anymore.

Since it's a pretty small change, I think we should go for it and see
how it behaves.

Thanks to @maan2003 this now also includes the same change to Wayland.

Release Notes:

- N/A

---------

Co-authored-by: maan2003 <manmeetmann2003@gmail.com>

![截屏2024-06-08 07 56
41](https://github.com/zed-industries/zed/assets/21101490/da97e7d4-458b-4262-ac23-a4704af4f015)

Release Notes:

- Added auto-completion support for `package.json` files.

Without this, `unsigned` or `unsigned int` is not highlighted properly:
`int` is a primitive_type but `unsigned` is a sized_type_specifier. This
is already handled in C as both are part of @type highlight group.

Before:

![image](https://github.com/zed-industries/zed/assets/1106629/7210b769-9dff-428c-9e4f-55b652f91674)

After:

![image](https://github.com/zed-industries/zed/assets/1106629/8661c412-30f0-4b44-a4a2-1860a0b56a4e)

Release Notes:

- N/A

Closes https://github.com/zed-industries/zed/issues/12609

Instead of adding some ordering mechanism to the actions, rename the
action so that it's not interfering with the `editor: restart language
server` command.

Before:

![image](https://github.com/zed-industries/zed/assets/2690773/b5e86eda-d766-49fc-a25b-f8b9fdb7b521)

![image](https://github.com/zed-industries/zed/assets/2690773/c5edeb56-12aa-496b-bb6f-dc705cbb9ae3)


After:

![image](https://github.com/zed-industries/zed/assets/2690773/ed30c68d-bfdd-4e00-bb5d-0be52fbe4e16)
![Screenshot 2024-06-05 at 09 46
25](https://github.com/zed-industries/zed/assets/2690773/9fe4eb52-0399-4321-85a9-3b07c11395ce)


Release Notes:

- Improved language server restart command ergonomics by renaming
`workspace::Restart` action into `workspace::Reload` to remove any other
"restart"-worded actions in the list

Release Notes:

- vim: Add `g/` for project search

This PR is an internal refactor in preparation for remote editing. It
restructures the public interface of `Worktree`, reducing the number of
call sites that assume that a worktree is local or remote.

* The Project no longer calls `worktree.as_local_mut().unwrap()` in code
paths related to basic file operations
* Fewer code paths in the app rely on the worktree's `LocalSnapshot`
* Worktree-related RPC message handling is more fully encapsulated by
the `Worktree` type.

to do:
* [x] file manipulation operations
* [x] sending worktree updates when sharing

for later
* opening buffers
* updating open buffers upon worktree changes

Release Notes:

- N/A

This is a PR with just a small visual adjustment, so instructions are
up-to-date with the new icon.
I did not remove the "old" ai.svg as I am not sure if its gonna be used
in the future or if its has been completely replaced by the new "zed
assistant" icon.

Release Notes:

- Fixed the wrong icon being used in the assistant setup instructions.

For open ai

<img width="543" alt="image"
src="https://github.com/zed-industries/zed/assets/61624214/5f18a8f4-6761-4df5-8482-92582545dee5">

and anthropic

<img width="544" alt="image"
src="https://github.com/zed-industries/zed/assets/61624214/6ca3ed23-0f68-4c0d-bc8a-32ab7c607029">

how it looked before (Zed Preview 0.139.3
0c083b7f381d8d75632c5ce5bd60810cda195ad0):

<img width="526" alt="image"
src="https://github.com/zed-industries/zed/assets/61624214/af9c9fa8-89ed-4f6a-88ca-b285b4c522c3">

Co-Authored-By: ethanmsl@gmail.com

Release Notes:

- vim: Added `gu`/`gU`/`g~` for changing case. (#12565)

Report a `open yarn project` `app_event` for each worktree where
`yarn.lock` is found and only report it once per session.

Release Notes:

- N/A

This PR adds a temporary block on publishing v0.0.7 of the
`zed_extension_api`.

We have breaking changes to the extension API that are currently staged
on `main` and are still being iterated on, so we don't want to publish
again until we're ready to commit to the new API.

This change is intended to prevent accidental publishing of the crate
before we're ready.

Release Notes:

- N/A

I'm not certain yet how it could be invalid, but we are still seeing
panics here.

Release Notes:

- Fixed a panic when opening the diagnostics view

This PR extends the `/fetch` command with support for Wikipedia code
blocks.

Release Notes:

- N/A

This PR extends the `/fetch` slash command with the initial support for
Wikipedia's HTML structure.

Release Notes:

- N/A

Release Notes:

- N/A

Fixes #12733 

Release Notes:

- Fixed drag&dropping project panel entries into editor area & tab bar

Release Notes:

- Added support for looking up the `rust-analyzer` binary in `$PATH`. This allows using such tools as `asdf` and nix to configure per-folder rust installations. To enable this behavior, use the `path_lookup` key when configuring the `rust-analyzer` `binary`: `{"lsp": {"rust-analyzer": {"binary": {"path_lookup": true }}}}`.

The `worktree` crate mainly provides an in-memory model of a directory
and its git repositories. But because it was originally extracted from
the Project crate, it also contained lingering bits of code that were
outside of that area:
* it had a little bit of logic related to buffers (though most buffer
management lives in `project`)
* it had a *little* bit of logic for storing diagnostics (though the
vast majority of LSP and diagnostic logic lives in `project`)
* it had a little bit of logic for sending RPC message (though the
*receiving* logic for those RPC messages lived in `project`)

In this PR, I've moved those concerns entirely to the project crate
(where they were already dealt with for the most part), so that the
worktree crate can be more focused on its main job, and have fewer
dependencies.

Worktree no longer depends on `client` or `lsp`. It still depends on
`language`, but only because of `impl language::File for
worktree::File`.

Release Notes:

- N/A

(Forgot in the other PR)

Release Notes:

- N/A

(Forgot to bump in the other PR)
Release Notes:

- N/A

This fixes #12728 as much as I can tell.

The problem was that inside ERB files, when inside Ruby code, we didn't
treat `-` as part of the word, which broke completions.

So, with the change in here, and the following Zed settings, it works.

```json
{
  "languages": {
    "Ruby": {
      "language_servers": ["tailwindcss-language-server", "solargraph"]
    }
  },
  "lsp": {
    "tailwindcss-language-server": {
      "settings": {
        "includeLanguages": {
          "erb": "html",
          "ruby": "html"
        },
        "experimental": {
          "classRegex": ["\\bclass:\\s*['\"]([^'\"]*)['\"]"]
        }
    }
  }
}
```

This enabled `tailwindcss-language-server` for Ruby files and tells the
language server to look for classes inside `class: ""` strings.

See demo video.

Release Notes:

- Fixed `tailwindcss-language-server` not being activated inside Ruby
strings (inside `.erb`)
([#12728](https://github.com/zed-industries/zed/issues/12728)).

Demo video:


https://github.com/zed-industries/zed/assets/1185253/643343b4-d64f-4c4e-98a1-d10df0b24e31

Co-authored-by: Max Brunsfeld <max@zed.dev>

This fixes #12402.

We already had the `tailwind-language-server` config in Astro's
`config.toml` here:
https://github.com/zed-industries/zed/blob/fd39f20842967f0fb8a6c508bc2e1ebaefbaf15f/extensions/astro/languages/astro/config.toml#L17-L23

But it's not enough to add `overrides.string` to the `config.toml`, you
also need an `overrides.scm` file that sets the overrides.

And, tricky bit, when you add a single override to the `overrides.scm`
file you have to add all of them that Zed knows about. In my case, I had
to add `@comment` too, because Zed somehow expects that.

Release Notes:

- Fixed `tailwind-language-server` not working in attributes inside of
`*.astro` files.
([#12402](https://github.com/zed-industries/zed/issues/12402)).

Demo/proof:


https://github.com/zed-industries/zed/assets/1185253/05677a2d-831d-4e05-a1a2-4d1730ce2a46

Release Notes:

- vim: Fix indent via `<` and `>` not being repeatable with `.`.
[#12351](https://github.com/zed-industries/zed/issues/12351)

Release Notes:

- Prevent folder expansion when all items are closed

### Problem
When all items are closed, the next activated file expands (see the
video below).


https://github.com/zed-industries/zed/assets/21101490/a7631cd2-4e97-4954-8b01-d283dd4796be


### Cause
When the currently active item is closed, Zed tries to activate the
previously active item. Activating an item by default expands the
corresponding folder, which can result in folders being expanded when
all files are closed.

### Fixed Video


https://github.com/zed-industries/zed/assets/21101490/d30f05c5-6d86-4e11-b349-337fa75586f3

Release Notes:

- N/A

Fixes case when `package.json` is not in root directory. 
Usually in mono repository, where multiple `package.json` may be present

Release Notes:

- Fixed runnable for package.json in monorepos

1.79 is due for release in a week.
Release Notes:

- N/A

This just changes nomenclature within the codebase and should have no
external effect.

Release Notes:

- N/A

Release Notes:

- Added search for saved contexts.
- Fixed a bug that caused titles generate by the LLM to be longer than
one line.