Closes #ISSUE

Release Notes:

- N/A

https://github.com/user-attachments/assets/92cc5ff7-d8be-4e4b-ac6e-68eb310fffce

Release Notes:

- Multibuffer headers will now stick to the top of the viewport as you
scroll
- Added support for expanding diagnostic excerpts

---------

Co-authored-by: Michael <michael@zed.dev>

This PR is a follow up to #22385 that makes it so we treat the icon as
derived state.

Release Notes:

- N/A

This PR adds just some tiny visual clean ups to the assistant2 panel.
Nothing major, honestly.

<img width="800" alt="Screenshot 2024-12-24 at 12 19 46 AM"
src="https://github.com/user-attachments/assets/da22aa7f-8a42-4ff0-9e4c-5e8b60b28802"
/>

Release Notes:

- N/A

This PR adds an icon field to the `ContextKind` enum, which means that
icons will now display on context pills, both on the message editor and
on the active thread.

<img width="800" alt="Screenshot 2024-12-24 at 12 23 17 AM"
src="https://github.com/user-attachments/assets/f00e540b-30fe-49ac-b3df-7c7a5dc86d65"
/>

Release Notes:

- N/A

Note the extra bottom space on the before version. That was because,
previously, the container that holds the context pills in an active
thread was being rendered even if there was no attached context.

| Before | After |
|--------|--------|
| <img width="1577" alt="Screenshot 2024-12-23 at 8 42 00 PM"
src="https://github.com/user-attachments/assets/b74bdc67-0a08-4d59-b1ec-43a00a59a373"
/> | <img width="1577" alt="Screenshot 2024-12-23 at 8 39 00 PM"
src="https://github.com/user-attachments/assets/1cbc340d-19df-4cce-8c0b-b671703a0ff5"
/> |

Release Notes:

- N/A

CSS has a brand new logo :) For context, see:

- https://github.com/CSS-Next/logo.css
- https://github.com/CSS-Next/logo.css/issues/54
- https://github.com/CSS-Next/logo.css/pull/53
- https://github.com/CSS-Next/logo.css/pull/55

<img width="1412" alt="Screenshot 2024-12-23 at 6 17 07 PM"
src="https://github.com/user-attachments/assets/7352a921-06fa-4e50-8aad-44c974c57ed4"
/>

Release Notes:

- Add new CSS logo

A lot of spacing tweaks. But, most notably, using the buffer font for
the inline assistant.

<img width="800" alt="Screenshot 2024-12-23 at 12 46 16 PM"
src="https://github.com/user-attachments/assets/ee2908a7-7515-4244-83fc-791172b29364"
/>

Release Notes:

- N/A

This PR visually balances code blocks within thread messages a bit more.

<img width="800" alt="Screenshot 2024-12-23 at 11 26 14 AM"
src="https://github.com/user-attachments/assets/6d459aac-5d94-4021-8289-0125bc82e77c"
/>

Release Notes:

- N/A

Improved image quality of docs site logo at top.

Prior Change: 
<img width="159" alt="SCR-20241218-konx"
src="https://github.com/user-attachments/assets/18c936e8-958d-4970-98e2-8dd1ad3a0a89"
/>
Post Change: 
<img width="177" alt="SCR-20241218-kojm"
src="https://github.com/user-attachments/assets/0b874ac2-7193-44ec-9634-b91a71c53864"
/>

Release Notes:

- N/A

---------

Co-authored-by: Danilo Leal <daniloleal09@gmail.com>

Also show all paths with issues, grouping them by the issue kind.

Inspired by https://github.com/zed-industries/zed/issues/22365 ,
https://github.com/zed-industries/zed/issues/20162,
https://github.com/zed-industries/zed/issues/13426, ...

Attempts to provide example `chown` and `chmod` commands on this error,
instead of encouraging to submit another issue.
For now, uses a hardcoded command examples, but we might provide a
better workflow later, e.g. try to automatically run those commands.

I seem to be unable to select the size of the modal, but for something
that's supposed to appear only once, it seems to be ok.


![regular](https://github.com/user-attachments/assets/484feb95-b9c5-445c-87f8-cd1db9337529)


![also_regular](https://github.com/user-attachments/assets/680ea95d-91fe-4b16-b3bc-e241ecd841d4)


![many_kinds](https://github.com/user-attachments/assets/7103161f-754d-413a-94df-62a44e353674)


![exaggerated](https://github.com/user-attachments/assets/b6e70be7-9ab4-4861-afae-5285a554fdba)



Release Notes:

- N/A

This somehow got lost during or after merge of #22202.

Release Notes:

- N/A

The domain has changed and the old StyLua arguments work again.

Release Notes:

- N/A

Closes #21406

Context:

A few weeks ago on Linux, we resolved an
[issue](https://github.com/zed-industries/zed/issues/20070) where users
could not open more than one file from the file explorer. This was fixed
by replacing `zed-editor` (zed binary in the code) with `zed` (cli
binary in the code) in the `.desktop` file. The reason for this change
was that using the cli to open files is more convenient - it determines
weather to spawn a new Zed instance or use an existing one, if we use
main binary instead it would throw error `Zed is already running`.

You can read the complete PR here: [linux: Fix file not opening from
file explorer](https://github.com/zed-industries/zed/pull/21137).

While this fix resolved the original issue, it introduced a new one.

Problem:

When the cli binary is used, it assumes it is always being invoked from
a terminal and relies on `std::env::vars()` to retrieve the environment
variables needed to spawn Zed. These env vars are then passed to the
worktree, and eventually, languages use the `PATH` from this env to find
binaries. This leads to the "Failed to start language server" error when
the `.desktop` entry is used on Linux.

Solution:

When the `zed-editor` binary is used, it uses some clever Unix-specific
logic to retrieve the default shell (`load_shell_from_passwd`) and then
fetch the env vars from that shell (`load_login_shell_environment`).
This same logic should be used in the cli binary when it is invoked via
a `.desktop` entry rather than from a terminal.

Approach:

I moved these two functions mentioned above to a utils file and reused
them in cli binary to fetch env vars only on Linux when it is not run
from a terminal. This provides missing paths, and fix the issue.

It is also possible to handle this in the `zed-editor` binary by
modifying the logic in `handle_cli_connection`, where `CliRequest::Open`
is processed. There we can discard incoming env, and use our logic. But
discarding incoming envs felt weird, and I thought it's better to handle
this at source.

Release Notes:

- Fixed `Failed to start language server` errors when starting from
dekstop entry on Linux

- [x] Upload separate debug symbols for Linux binaries to DigitalOcean
- [x] Send raw offsets with panic report JSON on Linux
- [x] Update `symbolicate` script to handle Linux crashes
- [x] Demangle backtraces 🎉 
- [x] Check that it works
- [x] Improve deduplication (?)
 
Release Notes:

- N/A

---------

Co-authored-by: Conrad <conrad@zed.dev>

Follow-up of https://github.com/zed-industries/zed/pull/21873

Release Notes:

- N/A

* Now more often displayed to the right. Resizes docs width if more
space than min width is available.

* If constrained in horizontal space and so displayed above/below resize
docs height to fit.

* Makes space for scrollbar and gap.

Layout is imperfect for viewport sizes smaller than the context menu,
left TODOs in the code for handling this. Wanted to get this change out
for feedback first.

Release Notes:

- N/A

Release Notes:

- In terminal context, `cmd-n` and `ctrl-n` now open a new terminal
instead of a new file

Disable them in the diff editors

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

Release Notes:

- N/A

This PR fixes a panic that could occur when confirming when the context
picker had no matching entries.

Release Notes:

- N/A

Makes a first pass over git panel UI, making it more interactive.


![image](https://github.com/user-attachments/assets/4d43b086-4ef2-4913-9783-2b9467d99c9a)


* every item can be selected, the selection is shown in the panel
* every item can be clicked, which changes the selection and
creates/focuses the editor with a project changes multi buffer
* the editor is scrolled so that the clicked item is in the center
* it's possible to nagivate up and down the panel, selecting
next/previous items in it, triggering the editor scroll

Known issues:

* entries are updated oddly sometimes (should become better after
DiffMap improvements land?)
* only unstaged diffs are shown currently (entry status storage should
help with this)
* no deleted files are displayed (the underlying work is done by others
now)
* added files have no diff hunks shown (DiffMap will have it?)
* performance story has not improved (again, DiffMap and status storage
should help with this)

Release Notes:

- N/A

@iamnbutler noticed slowness in assistant panel which I've pinned down
to the fact that we're calculating buffer diff on foreground thread.
This PR moves this computation into the background; I don't know much
about Zeta but it seems fine to do, as the call-site is asynchronous
anyways.

Closes #ISSUE

Release Notes:

- N/A

Follow-up to #22325, where I missed a couple points in the review that
were actually quite relevant.

Closes #ISSUE

Release Notes:

- N/A

Fixes: #22324

Closes #ISSUE

Release Notes:

- Fixed pytest decoracted function discovery

<img width="800" alt="Screenshot 2024-12-20 at 9 01 29 PM"
src="https://github.com/user-attachments/assets/5e9e9bf2-c84e-4215-b658-9b668dd151b2"
/>

Release Notes:

- N/A

<img width="800" alt="Screenshot 2024-12-20 at 8 52 27 PM"
src="https://github.com/user-attachments/assets/4b4f62a3-eb23-489b-a459-2117baaa37b4"
/>

Release Notes:

- N/A

The thread menu items were rendering with a larger font that the file &
directory counterparts. Now, they're consistent!

| Before | After | Reference |
|--------|--------|--------|
| <img width="800" alt="Screenshot 2024-12-20 at 8 39 47 PM"
src="https://github.com/user-attachments/assets/d196adcb-aea6-4399-8fb1-f5b771e76c1f"
/> | <img width="800" alt="Screenshot 2024-12-20 at 8 35 43 PM"
src="https://github.com/user-attachments/assets/a1e22c13-fd7e-4665-b09b-f3b583e7ce24"
/> | <img width="800" alt="Screenshot 2024-12-20 at 8 40 38 PM"
src="https://github.com/user-attachments/assets/d509ac6f-1251-4240-a369-906faebed8c0"
/> |


Release Notes:

- N/A

<img width="800" alt="Screenshot 2024-12-20 at 8 31 14 PM"
src="https://github.com/user-attachments/assets/1d7bd10a-0db3-41e4-9f59-977cc2ab137c"
/>

Release Notes:

- N/A

This PR removes the use of `use gpui::*` in the GPUI examples, as this
is not how consumers should be importing GPUI.

Release Notes:

- N/A

This PR removes usages of `use gpui::*;` in the codebase (excluding
examples).

We should only use glob imports for `gpui::prelude`, and then import
everything else individually.

Release Notes:

- N/A

Part of https://github.com/zed-industries/zed/issues/5363


https://github.com/user-attachments/assets/66c90cb7-1b36-4436-ad1e-344fbcd4befc

Release Notes:

- N/A

This is quite experimental and untested in languages other than Rust.
It's written to attempt to do something sensible in many languages. Due
to its experimental nature, just releasing to staff, and so not
including it in release notes. Future release note might be "Improved
diagnostic excerpts by using syntactic info to determine the context
lines to show."

Release Notes:

- N/A

Closes #17870

Context:

On Linux, when creating a new window, bounds are either pulled from
existing workspace data (serialized in an SQLite DB) or fall back to
some default constants if no data exists.

These bounds include the full dimensions of the window (width and
height), which already account for insets. However, properties like
`inset` (Wayland) or `last_insets` (X11) exist only at the platform
level and are not part of the window bounds themselves.

During rendering, we call `set_client_inset`, which updates the inset
values and also adjusts the window bounds, increasing their dimensions.
In Zed's case, the inset is 10px, which adds 20px to both the width and
height (10px from each side).

Problem:

When quitting, the full window bounds (which already account for inset)
are saved to the DB. On reopening, these saved bounds are used to create
the window. `set_client_inset` runs again and inflates the dimensions
even more.

Solution:

Store window bounds *without* the inset-inflated dimensions. On the next
session, `set_client_inset` will take care of applying the inset,
resulting window dimensions matching the previous session. This fix is
in the PR.

Alternative Solution:

Another option is to save the inset explicitly in the DB and apply it
during window creation. But this means storing more data, and the inset
would need to be platform-agnostic, which adds complexity. Doesn’t seem
worth it for no real gain.

X11 Before:
```sh
saving window bounds with width: 1136, height: 784
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.37s
     Running `target/debug/zed`
saving window bounds with width: 1156, height: 804   <---- +20px
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
     Running `target/debug/zed`
saving window bounds with width: 1176, height: 824  <---- +20px
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.36s
     Running `target/debug/zed`
saving window bounds with width: 1196, height: 844  <---- +20px
```

X11 After:
```sh
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
     Running `target/debug/zed`
saving window bounds with width: 1116, height: 764
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
     Running `target/debug/zed`
saving window bounds with width: 1116, height: 764     <---- same
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
     Running `target/debug/zed`
saving window bounds with width: 1116, height: 764   <---- same
```

On Wayland, saving occurs only when you actually resize the window (on
X11, saving happens both on init and while dragging the window). To
trigger saving, I manually resized the window by ~1px to make it print.

Wayland Before:
```sh
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 36s
     Running `target/debug/zed`
saving window bounds with width: 945, height: 577
tims@orange ~/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.77s
     Running `target/debug/zed`
saving window bounds with width: 966, height: 597    <--- +20px on both  (1px increase in width is me resizing)
tims@orange ~/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.87s
     Running `target/debug/zed`
saving window bounds with width: 987, height: 618    <--- +20px on both  (1px increase in width and height is me resizing)
tims@orange ~/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.89s
     Running `target/debug/zed`
saving window bounds with width: 1006, height: 638   <--- +20px on both  (1px decrease in width is me resizing)
```

Wayland After:
```sh
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.82s
     Running `target/debug/zed`
saving window bounds with width: 925, height: 558
tims@orange ~/zed (fix-window-growing-larger)> cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.84s
     Running `target/debug/zed`
saving window bounds with width: 925, height: 557     <--- same (1px decrease in height is me resizing)
saving window bounds with width: 925, height: 558
```

Release Notes:

- Fix non-maximized zed windows growing larger across sessions on Linux

---------

Co-authored-by: mgsloan@gmail.com <michael@zed.dev>

Leaving release notes as N/A because it had release notes in the past in
#21705

In #21286, documentation resolution was made more efficient by only
resolving the current completion. However, this meant that single line
documentation shown inline in the menu was missing until scrolled
to. This also meant that it would wait for navigation to resolve
completion docs, leading to lag for displaying documentation.

This change resolves this by attempting to fetch all the completions
that will be shown. It also mostly avoids re-resolving completions. It
intentionally re-resolves the current selection on navigation, as some
language servers will respond with more information later on.

Release Notes:

- N/A

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

<img width="800" alt="Screenshot 2024-12-20 at 6 45 50 PM"
src="https://github.com/user-attachments/assets/2069465f-1a00-47de-b691-585bb2603279"
/>

Release Notes:

- N/A

Makes the inline assistant look like @danilo-leal's prototype.

Also fixes the bug with indent guides that @maxdeviant found!

<img width="1059" alt="Screenshot 2024-12-20 at 4 24 56 PM"
src="https://github.com/user-attachments/assets/5e55a3c2-768a-4e9d-bad5-d4ebbe9db9ce"
/>

Release Notes:

- N/A

Release Notes:

- N/A

No issue attached, as this is something trivial and should have been
part of my merged PR
[here](https://github.com/zed-industries/zed/pull/22073).

For context, in the above-mentioned PR, I removed the hover color from
selected/marked entries in the Project Panel. The reasoning behind this
change is already explained in that PR, but to reiterate:

> This change was inspired by the behavior in VSCode, the Firefox
sidebar, and Dolphin (KDE File Manager). When an item is selected, it
doesn’t display a separate hover state to avoid confusing users about
whether the item is selected or merely hovered over.

@nilskch mentioned in the comments of the above PR that I should have
also changed the background of the knockout icon, which appears on
entries, to match the entry background color on hover. This PR addresses
that.

Before:

![Screenshot_20241219_230005](https://github.com/user-attachments/assets/fd517e01-1a1e-4e63-9320-ba24bf3d4c64)

After:

![Screenshot_20241219_225853](https://github.com/user-attachments/assets/35fb146f-83e4-409b-8061-0efbdbba5cf9)

Release Notes:

- N/A

- Follow up to: https://github.com/zed-industries/zed/pull/22170

CC: @mgsloan 

Release Notes:

- N/A

---------

Co-authored-by: Michael Sloan <mgsloan@gmail.com>

This PR temporarily restricts the directory context picker to
development builds until the implementation is finished.

Release Notes:

- N/A

This PR updates the directory context picker in Assistant2 to show the
available directories.

Release Notes:

- N/A

We've received a complaint on Discord about bad multicursor performance.
I too run 15k cursor simultaneously. The gist of the issue was in the
lsp_ext; whenever we gather up actions to be registered on a buffer, we
need to know whether a buffer has any of the languages for which we have
LSP extensions. The problem stemed from the fact that we did a two-phase
filtering. For each selection we'd first check whether this selection
lies in a part of a file that is part of a language for which we have
LSP extensions. Then, we'd check whether we're running a language server
of interest for this buffer.

This is not optimal, because it would often do the redundant work:
1. We resolve selections for buffer that are known to not contain a
given language server.
2. We look up language server in the LspStore once per each matching
selection.

In case where the file is not related at all, we end up resolving all of
the selections which is pretty bad. This PR makes us skip buffers which
are known to not match the criteria. It also caches the result of
language server lookup for the buffers.

Closes #ISSUE

Release Notes:

- Improved performance with large quantity of cursors

Follow-up to #22292

Release Notes:

- N/A

This message has confused me many times too: we printed the status as
"Downloading" when we were only checking whether we need to install a
given version of a language server.

This fixes the issue for Node-based language servers where we had the
same check in all implementations.

Closes  #22241

Release Notes:

- Fixed some language servers reporting status as "Downloading..." when
only a version check was being done.

This PR removes the gate that limited Assistant2 to development builds,
so that we can start testing it out in Nightly.

Note that currently this still requires explicit opt-in to the
`assistant2` feature flag.

Release Notes:

- N/A

Expands #18715

Release Notes:

- Added arrow keys movement to the built-in terminal's [vi
mode](https://github.com/alacritty/alacritty/blob/master/docs/features.md#vi-mode)
(which is using Alacritty under the hood).

Details
--
A minuscule improvement on #18715 to allow user with alternative
keyboard layouts to use the terminal's vi mode with the arrow keys.

Fixes #22151.

Turns out Vim also has some weird behavior with sentence deletion in
case it's on the first character of a line.

Release Notes:

- vim: Fixed deleting sentence-wise (i.e. `d(` and `d)`), which would
previously delete the whole line instead of just a sentence.

This PR ensures that, for fixed-width fonts, the cursor width is the
same on blank lines as on non-blank lines, as well as at the end of a
line. It does so by using the em advance to define the cursor width
instead of the em width in these cases.

Note that this can look... bizarre on non-fixed-width fonts:
<img width="93" alt="Screenshot 2024-12-19 at 21 43 11"
src="https://github.com/user-attachments/assets/a4c9b26c-98ea-4a1d-947b-51f1acd3c2f8"
/>
However, this is arguably reasonably consistent with how (terminal) Vim
handles it:
<img width="45" alt="Screenshot 2024-12-19 at 21 46 42"
src="https://github.com/user-attachments/assets/ec3ff614-7a15-4cc3-8d14-3d15ce62f2b8"
/>

Closes #22260.

Release Notes:

- N/A

Motivation for this is to support writing comments that will certainly
be revisited before merge.

Release Notes:

- N/A

Closes #22264

On Linux, the arrow cursor style currently used by Zed is `arrow`.
However, this style might not be available in most themes, causing the
cursor to fall back to system default theme. Note cursor style are
platform (X11 and Wayland) agnostic.

Most themes use `left_ptr` as their arrow cursor style instead of
`arrow`. In some cases, `left_ptr` and `arrow` are symlinks pointing to
the `default` style, but the `default` style is not guaranteed to be
available across all themes.

After inspecting the available cursor themes on popular desktop
environments, changing the default from `arrow` to `left_ptr` seems to
be available in all of them. `left_ptr` as default cursor style is also
mentioned in [Arch Wiki: Cursor
themes](https://wiki.archlinux.org/title/Cursor_themes#Change_X_shaped_default_cursor).

KDE:
```sh
tims@lemon /u/s/icons> find . -name "arrow"
./Breeze_Snow/cursors/arrow
./breeze_cursors/cursors/arrow
./Adwaita/cursors/arrow

tims@lemon /u/s/icons> find . -name "default"
./default
./Breeze_Snow/cursors/default
./breeze_cursors/cursors/default
./Adwaita/cursors/default

tims@lemon /u/s/icons> find . -name "left_ptr"
./Oxygen_White/cursors/left_ptr
./KDE_Classic/cursors/left_ptr
./Oxygen_Yellow/cursors/left_ptr
./Oxygen_Blue/cursors/left_ptr
./Oxygen_Black/cursors/left_ptr
./Breeze_Snow/cursors/left_ptr
./breeze_cursors/cursors/left_ptr
./Adwaita/cursors/left_ptr
./Oxygen_Zion/cursors/left_ptr

```

Gnome:
```sh
tims@orange:/usr/share/icons$ find . -name "arrow"
./DMZ-Black/cursors/arrow
./Adwaita/cursors/arrow
./redglass/cursors/arrow
./whiteglass/cursors/arrow
./handhelds/cursors/arrow
./Yaru/cursors/arrow
./DMZ-White/cursors/arrow

tims@orange:/usr/share/icons$ find . -name "default"
./Adwaita/cursors/default
./default
./Yaru/cursors/default

tims@orange:/usr/share/icons$ find . -name "left_ptr"
./DMZ-Black/cursors/left_ptr
./Adwaita/cursors/left_ptr
./redglass/cursors/left_ptr
./whiteglass/cursors/left_ptr
./handhelds/cursors/left_ptr
./Yaru/cursors/left_ptr
./DMZ-White/cursors/left_ptr
```

My theme is set to Oxygen Yellow here.

Before:
<img
src="https://github.com/user-attachments/assets/7485f1e7-5936-45b4-96bd-399525bad95d"
alt="before" width="450px" />

After:
<img
src="https://github.com/user-attachments/assets/56090735-6a1f-4652-ad3e-075ff4c3f9ab"
alt="after" width="450px" />


Release Notes:

- Fixed wrong cursor theme for arrow cursor style on Linux.