This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [ipc-channel](https://redirect.github.com/servo/ipc-channel) |
dependencies | minor | `0.18` -> `0.19` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xOS4wIiwidXBkYXRlZEluVmVyIjoiMzkuMTkuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Closes#14306
This looks at what #16660 did and install.sh script as a base for the
uninstall.sh script. The script is bundled with the cli by default
unless the cli/no-bundled-uninstall feature is selected which is done,
so package managers could build zed without bundling a useless feature
and increasing binary size.
I don't have capabilities to test this right now, so any help with that
is appreciated.
Release Notes:
- Added an uninstall script for Zed installations done via zed.dev. To
uninstall zed, run `zed --uninstall` via the CLI binary.
This changes the Zed CLI `zed` to pass along the environment to the Zed
project that it opens (if it opens a new one).
In projects, this CLI environment will now take precedence over any
environment that's acquired by running a login shell in a projects
folder.
The result is that `zed my/folder` now always behaves as if one would
run `zed --foreground` without any previous Zed version running.
Closes#7894Closes#16293
Related issues:
- It fixes the issue described in here:
https://github.com/zed-industries/zed/issues/4977#issuecomment-2305272027
Release Notes:
- Improved the Zed CLI `zed` to pass along the environment as it was on
the CLI to the opened Zed project. That environment is then used when
opening new terminals, spawning tasks, or language servers.
Specifically:
- If Zed was started via `zed my-folder`, a terminal spawned with
`workspace: new terminal` will inherit these environment variables that
existed on the CLI
- Specific language servers that allow looking up the language server
binary in the environments `$PATH` (such as `gopls`, `zls`,
`rust-analyzer` if configured, ...) will look up the language server
binary in the CLI environment too and use that environment when starting
the process.
- Language servers that are _not_ found in the CLI environment (or
configured to not be found in there), will be spawned with the CLI
environment in case that's set. That means users can do something like
`RA_LOG=info zed .` and it will be picked up the rust-analyzer that was
spawned.
Demo/explanation:
https://github.com/user-attachments/assets/455905cc-8b7c-4fc4-b98a-7e027d97cdfa
This PR extracts the definition of the various Zed paths out of `util`
and into a new `paths` crate.
`util` is for generic utils, while these paths are Zed-specific. For
instance, `gpui` depends on `util`, and it shouldn't have knowledge of
these paths, since they are only used by Zed.
Release Notes:
- N/A
- [x] Build out cli on linux
- [x] Add support for --dev-server-token sent by the CLI
- [x] Package cli into the .tar.gz
- [x] Link the cli to ~/.local/bin in install.sh
Release Notes:
- linux: Add cli support for managing zed
With this commit, it is now possible to invoke cli with a release
channel of bundle as an argument. E.g: `zed stable some_arguments` will
find CLI binary of Stable channel installed on your machine and invoke
it with `some_arguments` (so the first argument is essentially omitted).
Fixes#10851
Release Notes:
- CLI now accepts an optional name of release channel as it's first
argument. For example, `zed stable` will always use your Stable
installation's CLI. Trailing args are passed along.
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
This PR sets up a `cargo xtask clippy` command for running `cargo
clippy` with our defined set of options.
The intent is to make this easier to manage as we start enabling more
Clippy rules.
Release Notes:
- N/A
This is a follow up to #7945. The current behaviour reads the locale and
infers from that which type of time format should be used (12 hour/24
hour).
However, in macOS you can override this behaviour, e.g. you can use
en_US locale but still use the 24 hour clock format (Can be customized
under Settings > General > Date & Format > 24-hour time). You can even
customize the date format.
This PR uses the macOS specific `CFDateFormatter` API, which outputs
time format strings, that respect those settings.
Partially fixes#7956 (as its not implemented for linux)
Release Notes:
- Added localization support for all macOS specific date and time
configurations in chat
- [x] Fill in GPL license text.
- [x] live_kit_client depends on live_kit_server as non-dev dependency,
even though it seems to only be used for tests. Is that an issue?
Release Notes:
- N/A
We temporarily let it grow when the message size exceed the limit,
but restore the buffer's capacity shortly after. This ensures that,
for each connection in its entire lifetime, we only ever use 1MB.
We still aren't handling CLI requests in the app, but this lays the foundation for bi-directional communication.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Piotr Osiewicz