Release Notes:

- N/A

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

Release Notes:

- N/A

Release Notes:

- N/A

Co-authored-by: Marshall <marshall@zed.dev>

This PR makes the `StripeBilling` object long-lived so that we can make
better use of the cached data on it.

We now hold it on the `AppState` and spawn a background task to
initialize the cache on startup.

Release Notes:

- N/A

Co-authored-by: Richard <richard@zed.dev>

When setting a remote ssh project path starting with ~, Zed would fail
to cd into such project's directory when opening a new terminal.

Release Notes:

- N/A

---------

Co-authored-by: Thorsten Ball <mrnugget@gmail.com>

This PR sorts the order of the LLM database ID type declarations.

Release Notes:

- N/A

This PR adds usage-based billing for LLM interactions in the Assistant.

Release Notes:

- N/A

---------

Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Richard <richard@zed.dev>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>

collab: Remove dependency on X11

I'm not sure if this is the best solution (perhaps pulling
`LanguageName` into a separate `language_types` crate would be
better...?) - but it massively reduces build time / dependencies / size
and means that the collab server no longer requires X11 libraries to be
installed.

tl;dr: `telemetry_events` requires the `language` crate, and the
language crate requires a whole ton of extra stuff. Since
telemetry_events only uses `language` for a single type definition
(`LanguageName`, aka `String`), we can cut all of these out by using the
base `String` type (This doesn't seem too terrible, given that all other
telemetry fields are using basic datatypes like String as opposed to
more strongly-typed variants).


FYI the dependency tree for "why does collab need X11 libraries??" looks
like this:

```
collab
 \- telemetry_events
     \- language
         |- gpui
         |- fuzzy
         |   \- gpui
         |- git
         |   \- gpui
         |- lsp
         |   |- gpui
         |   \- release_channel
         |       \- gpui
         |- settings
         |   |- fs
         |   |   \- gpui
         |   \- gpui
         |- task
         |   \- gpui
         \- theme
             \- gpui
```

Release Notes:

- N/A

This PR adds support to the assistant for display billing-related
errors.

Pulling this out of #19081 to make it easier to cherry-pick.

Release Notes:

- N/A

Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Richard <richard@zed.dev>

terminal: Improve default locale handling

* Use `LANG` instead of `LC_ALL` (`LC_ALL` is the highest priority which
will override any other end-user settings; when that isn't set things
fall back to separate `LC_*` variables; and when those aren't set things
fall back to `LANG`). [0]
* Only set `LANG` for our child if necessary (if it already exists in
the parent, then the child will inherit that, no need for us to do
anything)

[0]
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02

Tested cases:

- `unset LANG ; cargo run`: locale inside zed's terminal is set to
`en_US.UTF-8`
- `export LANG=en_GB.UTF-8 ; cargo run`: locale inside zed's terminal is
set to `en_GB.UTF-8`

Release Notes:

- Use the system locale in the terminal instead of forcing `en_US.UTF-8`

Release Notes:

- N/A

---------

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

This PR transfers the Gleam extension over to the @gleam-lang
organization:

https://github.com/gleam-lang/zed-gleam

Release Notes:

- N/A

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

This fixes incorrect width estimates and horizontal scrollbar glitches

Release Notes:

- Fixes horizontal scrollbar not scrolling enough for certain paths
([#18939](https://github.com/zed-industries/zed/issues/18939))

Co-authored-by: Piotr Osiewicz <piotr@zed.dev>

Clicking on

<img width="361" alt="image"
src="https://github.com/user-attachments/assets/b55e2575-b438-4c26-922f-313dc1f41fea">

now opens a read only buffer

<img width="547" alt="image"
src="https://github.com/user-attachments/assets/af82e104-1603-4fe4-9351-635a02cfb4f9">

Previously the buffer would show up as a normal untitled buffer and
would open a prompt when closing the tab.

Co-Authored-by: Thorsten <thorsten@zed.dev>

Release Notes:

- N/A

Co-authored-by: Thorsten <thorsten@zed.dev>

Closes #19050

Release Notes:

- Fixed `worktree.read_text_file` plugin API working incorrectly
([#19050](https://github.com/zed-industries/zed/issues/19050))

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

Release Notes:

- Fixed Zed not being open filenames with special combination of
brackets ([#18268](https://github.com/zed-industries/zed/issues/18268))

This fixes two things:

- Go-to-def to absolute paths (i.e. opening stdlib files) multiple times
(opening, dropping, and re-opening worktrees)
- Re-opening abs paths from the file picker history that were added
there by go-to-def


Release Notes:

- N/A

---------

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

Currently terminal.cursor_shape uses `underline` and `cursor_shape` uses
`underscore`.
This standardizes them so they use the same settings value.

I think `underline` is the more common term and it matches the
terminology used by VSCode, Alacritty, iTerm, etc.

Note the protobuf enum `CursorShape::CursorUnderscore` remains
unchanged.

See also:
- https://github.com/zed-industries/zed/pull/18530
- https://github.com/zed-industries/zed/pull/17572

Release Notes:

- Settings: rename one `cursor_shape` from `underscore` to `underline`
(breaking change).

This is a bit of a personal thing, but it's been bugging me for a while
now that the search options are sticky whenever I use `/` in Vim mode.

This change makes it so that the options are reset with each new `/`.

That means you can, for example, use `v` to create a visual selection,
then hit `*` to search for that (which activates a bunch of search
options), but then continue with `/` to get a normal search.

Release Notes:

- Changed `/` in Vim mode to always reset the search options in the
search bar back to regex-only. That means using `*` (in normal or visual
mode) still works with its options, but the next `/` will reset the
search options. That makes it much closer to how `/` behaves in Vim.

Release Notes:

- N/A

- The App Shortcuts in macOS System Settings does not work for Zed since the menu items titles were not set.
- Previously you could set a shortcut for `Zoom`.
- This add support for `Window->Zoom` as well.

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

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [wasmtime](https://redirect.github.com/bytecodealliance/wasmtime) |
workspace.dependencies | patch | `24.0.0` -> `24.0.1` |

### GitHub Vulnerability Alerts

####
[CVE-2024-47763](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg)

### Impact

Wasmtime's implementation of WebAssembly tail calls combined with stack
traces can result in a runtime crash in certain WebAssembly modules. The
runtime crash may be undefined behavior if Wasmtime was compiled with
Rust 1.80 or prior. The runtime crash is a deterministic process abort
when Wasmtime is compiled with Rust 1.81 and later.

[WebAssembly tail
calls](https://redirect.github.com/webassembly/tail-call) are a proposal
which relatively recently reached stage 4 in the [standardization
process](https://redirect.github.com/WebAssembly/proposals/). Wasmtime
first enabled support for tail calls by default [in Wasmtime
21.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8540),
although that release contained a bug where it was only on-by-default
for some configurations. In [Wasmtime
22.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8682)
tail calls were enabled by default for all configurations.

The specific crash happens when an exported function in a WebAssembly
module (or component) performs a `return_call` (or
`return_call_indirect` or `return_call_ref`) to an imported host
function which captures a stack trace (for example, the host function
raises a trap). In this situation, the stack-walking code previously
assumed there was always at least one WebAssembly frame on the stack but
with tail calls that is no longer true. With the tail-call proposal it's
possible to have an entry trampoline appear as if it directly called the
exit trampoline. This situation triggers an internal assert in the
stack-walking code which raises a Rust `panic!()`.

When Wasmtime is compiled with Rust versions 1.80 and prior this means
that an `extern "C"` function in Rust is raising a `panic!()`. This is
technically undefined behavior and typically manifests as a process
abort when the unwinder fails to unwind Cranelift-generated frames. When
Wasmtime is compiled with Rust versions 1.81 and later this panic
becomes a deterministic process abort.

Overall the impact of this issue is that this is a denial-of-service
vector where a malicious WebAssembly module or component can cause the
host to crash. There is no other impact at this time other than
availability of a service as the result of the crash is always a crash
and no more.

This issue was discovered by routine fuzzing performed by the Wasmtime
project via Google's OSS-Fuzz infrastructure. We have no evidence that
it has ever been exploited by an attacker in the wild.

### Patches

All versions of Wasmtime which have tail calls enabled by default have
been patched:

* 21.0.x - patched in 21.0.2
* 22.0.x - patched in 22.0.1
* 23.0.x - patched in 23.0.3 
* 24.0.x - patched in 24.0.1
* 25.0.x - patched in 25.0.2

Wasmtime versions from 12.0.x (the first release with experimental tail
call support) to 20.0.x (the last release with tail-calls
off-by-default) have support for tail calls but the support is disabled
by default. These versions are not affected in their default
configurations, but users who explicitly enabled tail call support will
need to either disable tail call support or upgrade to a patched version
of Wasmtime.

### Workarounds

The main workaround for this issue is to disable tail support for tail
calls in Wasmtime, for example with
[`Config::wasm_tail_call(false)`](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_tail_call).
Users are otherwise encouraged to upgrade to patched versions.

### References

* [Wasmtime's initial implementation of tail
calls](https://redirect.github.com/bytecodealliance/wasmtime/pull/6774)
* [Enabling of tail calls in
21.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8540)
* [Fully enabling tail calls in
22.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8682)
* [The WebAssembly's `tail-call`
proposal](https://redirect.github.com/webassembly/tail-call)

####
[CVE-2024-47813](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7qmx-3fpx-r45m)

### Impact

Under certain concurrent event orderings, a `wasmtime::Engine`'s
internal type registry was susceptible to double-unregistration bugs due
to a race condition, leading to panics and potentially type registry
corruption. That registry corruption could, following an additional and
particular sequence of concurrent events, lead to violations of
WebAssembly's control-flow integrity (CFI) and type safety. Users that
do not use `wasmtime::Engine` across multiple threads are not affected.
Users that only create new modules across threads over time are
additionally not affected.

Reproducing this bug requires creating and dropping multiple type
instances (such as `wasmtime::FuncType` or `wasmtime::ArrayType`)
concurrently on multiple threads, where all types are associated with
the same `wasmtime::Engine`. **Wasm guests cannot trigger this bug.**
See the "References" section below for a list of Wasmtime types-related
APIs that are affected.

Wasmtime maintains an internal registry of types within a
`wasmtime::Engine` and an engine is shareable across threads. Types can
be created and referenced through creation of a `wasmtime::Module`,
creation of `wasmtime::FuncType`, or a number of other APIs where the
host creates a function (see "References" below). Each of these cases
interacts with an engine to deduplicate type information and manage type
indices that are used to implement type checks in WebAssembly's
`call_indirect` function, for example. This bug is a race condition in
this management where the internal type registry could be corrupted to
trigger an assert or contain invalid state.

Wasmtime's internal representation of a type has individual types (e.g.
one-per-host-function) maintain a registration count of how many time
it's been used. Types additionally have state within an engine behind a
read-write lock such as lookup/deduplication information. The race here
is a time-of-check versus time-of-use (TOCTOU) bug where one thread
atomically decrements a type entry's registration count, observes zero
registrations, and then acquires a lock in order to unregister that
entry. However, between when this first thread observed the
zero-registration count and when it acquires that lock, another thread
could perform the following sequence of events: re-register another copy
of the type, which deduplicates to that same entry, resurrecting it and
incrementing its registration count; then drop the type and decrement
its registration count; observe that the registration count is now zero;
acquire the type registry lock; and finally unregister the type. Now,
when the original thread finally acquires the lock and unregisters the
entry, it is the second time this entry has been unregistered.

| Thread A                          | Thread B                       |
|-----------------------------------|--------------------------------|
| `acquire(type registry lock)`     |                                |
|                                   | `decref(E) --> 0`              |
|                                   | `block_on(type registry lock)` |
| `register(E') == incref(E) --> 1` |                                |
| `release(type registry lock)`     |                                |
| `decref(E) --> 0`                 |                                |
| `acquire(type registry lock)`     |                                |
| `unregister(E)`                   |                                |
| `release(type registry lock)`     |                                |
|                                   | `acquire(type registry lock)`  |
|                                   | `unregister(E)`          |

This double-unregistration could then lead to a WebAssembly CFI
violation under the following conditions: a new WebAssembly module `X`
was loaded into the engine before the second, buggy unregistration
occurs; `X` defined a function type `F` that was allocated in the same
type registry slot where the original entry was allocated; the second,
buggy unregistration incorrectly unregistered `F`; another new
WebAssembly module `Y` was loaded into the engine; `Y` defined a
function type `G`, different from `F`, but which is also allocated in
the same type registry slot; a `funcref` of type `G` is created, either
by the host or by Wasm; that `funcref` is passed to a WebAssembly
instance of module `X`; that instance performs a `call_indirect` to that
`funcref`; the `call_indirect`'s dynamic type check, which preserves
CFI, could incorrectly pass in this case, because `F` and `G` were
assigned the same type registry slot. This would, ultimately, allow
calling a function with too many, too few, or wrongly-typed arguments,
violating CFI and type safety.

We were not able to reproduce this CFI violation in a vanilla Wasmtime
build, although it remains theoretically possible. However, by modifying
Wasmtime's source code to make losing the races described above more
likely (by disabling certain assertions, inserting panic catches, and
adding retry loops in a few places if we did *not* lose the race) we
were able to incorrectly get a `funcref` to pass a type check that it
should have failed, which would allow the CFI violation.

### Patches

This bug was originally introduced in Wasmtime 19's development of the
WebAssembly GC proposal. This bug affects users who are not using the GC
proposal, however, and affects Wasmtime in its default configuration
even when the GC proposal is disabled. Wasmtime users using 19.0.0 and
after are all affected by this issue. We have released the following
Wasmtime versions, all of which have a fix for this bug:

* 21.0.2
* 22.0.1
* 23.0.3
* 24.0.1
* 25.0.2

### Workarounds

If your application creates and drops Wasmtime types on multiple threads
concurrently, there are no known workarounds. Users are encouraged to
upgrade to a patched release.

### References

The following APIs create or drop types, and therefore are affected by
this race condition if performed on multiple threads concurrently and
are all associated with the same `wasmtime::Engine`:

*
[`wasmtime::FuncType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.FuncType.html#method.new)
* Also reachable from creation of
[`wasmtime::Func`](https://docs.rs/wasmtime/latest/wasmtime/struct.Func.html)
* Also reachable from
[`wasmtime::Linker::func_*`](https://docs.rs/wasmtime/latest/wasmtime/struct.Linker.html#method.func_new)
*
[`wasmtime::ArrayType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayType.html#method.new)
*
[`wasmtime::StructType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructType.html#method.new)
*
[`wasmtime::Func::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Func.html#method.ty)
*
[`wasmtime::Global::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Global.html#method.ty)
*
[`wasmtime::Table::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Table.html#method.ty)
*
[`wasmtime::Extern::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Extern.html#method.ty)
*
[`wasmtime::Export::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Export.html#method.ty)
*
[`wasmtime::UnknownImportError::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.UnknownImportError.html#method.ty)
*
[`wasmtime::ImportType::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ImportType.html#method.ty)
*
[`wasmtime::ExportType::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ExportType.html#method.ty)
*
[`wasmtime::Val::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Val.html#method.ty)
*
[`wasmtime::Ref::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Ref.html#method.ty)
*
[`wasmtime::AnyRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.AnyRef.html#method.ty)
*
[`wasmtime::EqRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.EqRef.html#method.ty)
*
[`wasmtime::ArrayRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayRef.html#method.ty)
*
[`wasmtime::StructRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructRef.html#method.ty)
* Dropping a
[`wasmtime::FuncType`](https://docs.rs/wasmtime/latest/wasmtime/struct.FuncType.html)
* Dropping a
[`wasmtime::ArrayType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayType.html)
* Dropping a
[`wasmtime::StructType`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructType.html)
* Dropping a
[`wasmtime::ExternType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ExternType.html)
* Dropping a
[`wasmtime::GlobalType`](https://docs.rs/wasmtime/latest/wasmtime/struct.GlobalType.html)
* Dropping a
[`wasmtime::TableType`](https://docs.rs/wasmtime/latest/wasmtime/struct.TableType.html)
* Dropping a
[`wasmtime::ValType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ValType.html)
* Dropping a
[`wasmtime::RefType`](https://docs.rs/wasmtime/latest/wasmtime/struct.RefType.html)
* Dropping a
[`wasmtime::HeapType`](https://docs.rs/wasmtime/latest/wasmtime/struct.HeapType.html)
* Dropping a
[`wasmtime::UnknownImportError`](https://docs.rs/wasmtime/latest/wasmtime/struct.UnknownImportError.html)
* Dropping a
[`wasmtime::Linker`](https://docs.rs/wasmtime/latest/wasmtime/struct.Linker.html)

The change which introduced this bug was
[#​7969](https://redirect.github.com/bytecodealliance/wasmtime/pull/7969)

---

### Release Notes

<details>
<summary>bytecodealliance/wasmtime (wasmtime)</summary>

###
[`v24.0.1`](https://redirect.github.com/bytecodealliance/wasmtime/releases/tag/v24.0.1)

[Compare
Source](https://redirect.github.com/bytecodealliance/wasmtime/compare/v24.0.0...v24.0.1)

#### 24.0.1

Released 2024-10-09.

##### Fixed

- Fix a runtime crash when combining tail-calls with host imports that
capture a
    stack trace or trap.

[GHSA-q8hx-mm92-4wvg](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg)

- Fix a race condition could lead to WebAssembly control-flow integrity
and type
    safety violations.

[GHSA-7qmx-3fpx-r45m](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7qmx-3fpx-r45m)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "" in timezone America/New_York,
Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC4xMTQuMCIsInVwZGF0ZWRJblZlciI6IjM4LjExNC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

As Zed instantly shows completion items in the completion menu, and the
resolve will cause the details to appear, flickering.
We can safely resolve the `documentation`, `additionalTextEdits` and
`command` fields, the rest should be resolved eagerly for now.

Release Notes:

- Fixed completion menu rendering

indents jsx in a way that is [consistent with
html](https://github.com/zed-industries/zed/blob/main/extensions/html/languages/html/indents.scm)

before, no automatic indentation would apply and it would even dedent
you when you add a line above the cursor (shift-o in vim mode)


https://github.com/user-attachments/assets/470fbdb2-3e31-42c4-b535-bb26ae1706ab


after, it applies automatic indentation when you hit return


https://github.com/user-attachments/assets/e86c739d-370d-490d-8c6f-d0190e65f832



Closes #16127

Release Notes:

- Improved automatic indentation behavior in JSX
([#16127](https://github.com/zed-industries/zed/issues/16127))

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
|
[actions/upload-artifact](https://redirect.github.com/actions/upload-artifact)
| action | digest | `5076954` -> `604373d` |

---

### Configuration

📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC4xMTQuMCIsInVwZGF0ZWRJblZlciI6IjM4LjExNC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Track the cursor offset before biasing in the Supermaven completion
provider to better determine if the text should be suggested. The
underlying issue here is due to the way anchor biasing works, the
completion provider is not able to determine if a given suggestion's
cursor location no longer exists as it is always coalesced to a correct
location (specifically, the end of the line).

This change updates that logic so the offset is stored independently of
the buffer so it can be used to represent a location that may not exist
in the buffer anymore to represent locations that have been deleted.

The net effect is that suggestions can be backspaced much more cleanly
with Supermaven.


![image](https://github.com/user-attachments/assets/ff61aa09-54ea-4cad-b1ca-633a08bcdd96)


![image](https://github.com/user-attachments/assets/b49e2d6b-f1d3-41a1-9b75-c4bc3ac5f85b)

Release Notes:

- Improves https://github.com/zed-industries/zed/issues/17981 to prevent
suggesting completions based on out-of-date cursor locations.

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [ashpd](https://redirect.github.com/bilelmoussaoui/ashpd) |
workspace.dependencies | patch | `0.9.1` -> `0.9.2` |

---

### Release Notes

<details>
<summary>bilelmoussaoui/ashpd (ashpd)</summary>

###
[`v0.9.2`](https://redirect.github.com/bilelmoussaoui/ashpd/releases/tag/0.9.2)

[Compare
Source](https://redirect.github.com/bilelmoussaoui/ashpd/compare/0.9.1...0.9.2)

#### What's Changed

- [desktop: Make trait SessionPortal
public](https://redirect.github.com/bilelmoussaoui/ashpd/pull/240/commits/0d2dad594ee9a98799895a92e23e52b2250eaf9c)
- [lib: Add Pid
type](https://redirect.github.com/bilelmoussaoui/ashpd/pull/240/commits/96b27e70692d34a10ed6537d732ced5e74f96b04)
- [desktop/game_mode: Use i32 for
pid](https://redirect.github.com/bilelmoussaoui/ashpd/pull/240/commits/336917a4ed4e88f536a9901c9befc0938f9fdcdb)
- [desktop/device: Use Pid type for
pids](https://redirect.github.com/bilelmoussaoui/ashpd/pull/240/commits/c05b3c17f8f6a4a769c69a778d4cd8fea22dd784)
- [flatpak: Use Pid type for
pids](https://redirect.github.com/bilelmoussaoui/ashpd/pull/240/commits/55a6ea0c9d89c34bf65a3be0c75a7d9771c3848c)
- [is_sandboxed: Don't unwrap OnceCell
set](https://redirect.github.com/bilelmoussaoui/ashpd/pull/240/commits/5d3cb4170772351095bed2bf55075c1498df139d)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC4xMTQuMCIsInVwZGF0ZWRJblZlciI6IjM4LjExNC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [proc-macro2](https://redirect.github.com/dtolnay/proc-macro2) |
dependencies | patch | `1.0.86` -> `1.0.87` |

---

### Release Notes

<details>
<summary>dtolnay/proc-macro2 (proc-macro2)</summary>

###
[`v1.0.87`](https://redirect.github.com/dtolnay/proc-macro2/releases/tag/1.0.87)

[Compare
Source](https://redirect.github.com/dtolnay/proc-macro2/compare/1.0.86...1.0.87)

- Check valid punctuation character in `Punct::new`
([#&#8203;470](https://redirect.github.com/dtolnay/proc-macro2/issues/470))

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC4xMTQuMCIsInVwZGF0ZWRJblZlciI6IjM4LjExNC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [ipc-channel](https://redirect.github.com/servo/ipc-channel) |
dependencies | patch | `0.18.2` -> `0.18.3` |

---

### Configuration

📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC45Ny4wIiwidXBkYXRlZEluVmVyIjoiMzguOTcuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
|
[async-compression](https://redirect.github.com/Nullus157/async-compression)
| workspace.dependencies | patch | `0.4.12` -> `0.4.13` |

---

### Release Notes

<details>
<summary>Nullus157/async-compression (async-compression)</summary>

###
[`v0.4.13`](https://redirect.github.com/Nullus157/async-compression/blob/HEAD/CHANGELOG.md#0413---2024-10-02)

[Compare
Source](https://redirect.github.com/Nullus157/async-compression/compare/v0.4.12...v0.4.13)

##### Feature

-   Update `brotli` dependency to to `7`.

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC45Ny4wIiwidXBkYXRlZEluVmVyIjoiMzguOTcuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [emojis](https://redirect.github.com/rossmacarthur/emojis) |
workspace.dependencies | patch | `0.6.3` -> `0.6.4` |

---

### Release Notes

<details>
<summary>rossmacarthur/emojis (emojis)</summary>

###
[`v0.6.4`](https://redirect.github.com/rossmacarthur/emojis/compare/0.6.3...0.6.4)

[Compare
Source](https://redirect.github.com/rossmacarthur/emojis/compare/0.6.3...0.6.4)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC45Ny4wIiwidXBkYXRlZEluVmVyIjoiMzguOTcuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

- Closes #18610


This PR addresses the same issue as PR #18578. After a full day of
research and testing, I believe I’ve found the best solution to resolve
this issue. With this PR, the window creation behavior on Windows
becomes more consistent with macOS:

- When `params.show` is `true`: The window is created and immediately
displayed.
- When `params.show` is `false`: The window is created but remains
hidden until the first call to `activate_window`.

As I mentioned in #18578, `winit` creates hidden windows by setting the
window's `exstyle` to `WS_EX_NOACTIVATE | WS_EX_TRANSPARENT |
WS_EX_LAYERED | WS_EX_TOOLWINDOW`, which is different from the method
used in this PR. Here, the window is created with normal parameters, but
we do not call `ShowWindow` so the window is not shown.

I'm not sure why `winit` doesn't use a smilliar approach like this PR to
create hidden windows. My guess is that `winit` is creating this hidden
window to function as a "DispatchWindow" — serving a purpose similar to
`WindowsPlatform` in `zed`. To ensure the window stays hidden even if
`ShowWindow` is called, they use the `exstyle` approach.

With the method used in this PR, my initial tests haven't revealed any
issues.



Release Notes:

- N/A

Demo:



https://github.com/user-attachments/assets/e5edf8f3-8c15-482e-a792-6eb619f83de4


Release Notes:

- N/A

---------

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

[terminal] Consider "main.cs(20,5)" to be a single clickable word

First, adding unit tests for the regexes because I'm not certain how
these regexes are _intended_ to work, and unit tests work nicely as
demonstrations of intended behaviour.

The comment string, and the regex itself, seem to imply that
"main.cs(20,5)" is supposed be a single "word" (for the purposes of
being clicked on)... but the regex doesn't actually work like that. This
PR makes it work :)

(I don't know _why_ "word with an optional `(\d+,\d+)` on the end"
doesn't match the full string, while "word with a required `(\d+,\d+)`
on the end" _does_ match the full string - aren't regexes supposed to
match as much as possible, so it should take the optional extra whenever
the extra exists? Either way, "word with a required (\d+,\d+), or word
by itself" has the correct behaviour, as demonstrated by the unit test)

Release Notes:

- N/A

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

Release Notes:

- Fixed completion items inserted with a delay
([#19005](https://github.com/zed-industries/zed/issues/19005))

---------

Co-authored-by: Antonio Scandurra <antonio@zed.dev>

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


Release Notes:

- Intermediate auto-folded project panel entries are now clickable.

Release Notes:

- N/A

---------

Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>

Closes #7417

Release Notes:

- Added basic support for Alacritty's [vi
mode](https://github.com/alacritty/alacritty/blob/master/docs/features.md#vi-mode)
to the built-in terminal (which is using Alacritty under the hood.) The
vi mode can be activated with `ctrl-shift-space` and then supports some
basic motions to navigate through the terminal's scrollback buffer.

## Details

Leverages existing selection functionality from mouse_drag and the
ViMotion API of alacritty to add basic vi motions in the terminal.
Please note, this is only basic functionality (move, select, and yank to
system clipboard) and not a fully functional vim environment (e.g.
search, configurable keybindings, and paste). I figured this would be an
interim solution to the long term, more fleshed out, solution proposed
by @mrnugget.

Ctrl+Shift+Space to enter Vi mode while in the terminal (Same default
binding in alacritty)

Release Notes:

- Fixed a bug where auto-indent was not enabled while typing in
multi-buffers

Release Notes:

- N/A

I'm going to write something more robust using PyGitHub.

Release Notes:

- N/A

Release Notes:

- N/A

* `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

This PR fixes some issues with our previous approach to synching LLM
usage over to Stripe.

We now have a separate LLM access price in Stripe that is a marker price
to allow us to create the initial subscription with that as its
subscription item

We then dynamically set the LLM usage price during the reconciliation
sync based on the usage for the current month.

Release Notes:

- N/A

---------

Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Richard <richard@zed.dev>

This PR makes the `has_llm_subscription` and
`max_monthly_spend_in_cents` fields in the `LlmTokenClaims` required.

This change will be safe to deploy in ~45 minutes.

Release Notes:

- N/A