Closes#18393
Release Notes:
- Added a `ZED_RC_TOOLKIT_PATH` env variable so `winresource` crate can fetch the RC executable path correctly on some configurations
Users of our http_client crate knew they were interacting with isahc as
they set its extensions on the request. This change adds our own
equivalents for their APIs in preparation for changing the default http
client.
Release Notes:
- N/A
This should fix the `unregistered setting type
workspace::workspace_settings::WorkspaceSettings` panic that came from
inside `restorable_workspace_locations`.
We tracked it down to a possible scenario (we can't recreate it though)
in which `app.on_reopen` is called before the app has finished
launching.
In any case, this check makes sense, because we only want to restore a
workspace in case the whole app has launched with a UI.
Release Notes:
- N/A
Co-authored-by: Bennet <bennet@zed.dev>
This PR adds some more functionality to the Proposed Changes Editor
view, which we'll be using in
https://github.com/zed-industries/zed/pull/18240 for allowing the
assistant to propose changes to a set of buffers.
* Add an `Apply All` button, and fully implement applying of changes to
the base buffer
* Make the proposed changes editor searchable
* Fix a bug in branch buffers' diff state management
Release Notes:
- N/A
Release Notes:
- Fixed overriding the path of a language server binary for all language
servers. `{"lsp":{"<lsp-name>":{"binary":{"path": "_"}}}}` will now work
for all language servers including those defined by extensions.
- (breaking change) To disable finding lsp adapters in your path, you
must now specify
`{"lsp":{"<lsp-name>":{"binary":{"ignore_system_version": true}}}}`.
Previously this was `{"lsp":{"<lsp-name>":{"binary":{"path_lookup":
false}}}}`. Note that this setting still does not apply to extensions.
- Removed automatic reinstallation of language servers. (It mostly
didn't work)
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Release Notes:
- (Potentially breaking change) Zed will now use the node installed on
your $PATH (if it is more recent than v18) instead of downloading its
own. You can disable the new behavior with `{"node":
{"disable_path_lookup": true}}` in your settings. We do not yet use
system/project-local node_modules.
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Closes#16876
We only ever showed parsing errors, but not if something failed to
deserialize.
Basically, if you had a stray `,` somewhere, we'd show a notification
for user errors, but only squiggly lines if you had a `[]` instead of a
`{}`.
The squiggly lines would only show up when there were schema errors.
In the case of `formatter` settings, for example, if someone put in a
`{}` instead of `[]`, we'd never show anything.
With this change we always show a notification if parsing user or
project settings fails.
(Right now, the error message might still be bad, but that's a separate
change)
Release Notes:
- Added a notification to warn users if their user settings or
project-local settings failed to deserialize.
Demo:
https://github.com/user-attachments/assets/e5c48165-f2f7-4b5c-9c6d-6ea74f678683
TODOs:
- [x] Add tests to `workspace/src/persistence.rs`
- [x] Add a icon for ssh projects
- [x] Fix all `TODO` comments
- [x] Use `port` if it's passed in the ssh connection options
In next PRs:
- Make sure unsaved buffers are persisted/restored, along with other
items/layout
- Handle multiple paths/worktrees correctly
Release Notes:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
This PR adds `system_id` to telemetry, which is contained within a new
`global` database (accessible by any release channel of Zed on a single
system). This will help us get a more accurate understanding of user
count, instead of relying on `installationd_id`, which is different per
release channel. This doesn't solve the problem of a user with multiple
machines, but it gets us closer.
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/5291
Release Notes:
- Fixed a bug where the 'toggle comments' command didn't use the right
comment syntax in JSX and TSX elements.
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Closes#4607
This is an attempt to enable Zed to run under multiple user accounts on
the same Mac, because it's a blocker to me really giving Zed a fair shot
at being my primary editor.
According to some helpful info from @ForLoveOfCats in #4607 the main
reason why this doesn't work is because Zed is using a Unix socket or
maybe a TCP socket with a hard-coded path and/or port. To me it looks
like it's a TCP socket so I tried changing that code in here, but I'm
stuck at trying to test it out because running `target/debug/zed` or
`target/release/zed` seems to behave differently than running an actual
app bundle. I had no luck copying the binary over to
/Applications/Zed.app/Contents/MacOS/zed because it can't find
WebRTC.framework which resides at a different relative path in the app
bundle.
If this seems like a desirable change to the core team then I'm looking
for some guidance on how to build an app bundle or otherwise test out
this change, or a nudge in the correct direction if I'm way off base
with my current approach.
Release Notes:
- Added multiuser support for up to 100 users on the same machine.
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR reverts #17173, as it introduced a segfault when opening any
Gleam project and the language server starts up.
This reverts commit a850731b0e.
Release Notes:
- N/A
Context: https://x.com/fasterthanlime/status/1819120238228570598
Up to this PR:
- We were not watching paths outside of a worktree when language server
requested it.
- We expected GlobPattern used for file watching to be always rooted at
the worktree root.
'1 mattered for observing global files (e.g. global RA config) and both
points had impact on "monorepos".
Let's picture the following scenario:
You're working on a Rust project that has two crates: bin and lib crate:
```
my-rust-project/
bin-crate/
lib-crate/
```
Up to this PR, making changes like changing field visibility in
lib-crate **was not reflected** in bin-crate until RA was restarted. RA
for bin-crate asked us to watch lib-crate. Now, depending on if you had
this project open as:
- a project with one worktree rooted at my-rust-project:
- due to '2, we never noticed that we have to notify RA instance for
bin-crate about changes in lib-crate.
- a project with two worktrees (bin-crate and lib-crate):
- due to '1 (as lib-crate is not within bin-crate's worktree), we once
again missed the fact that we have to watch for changes in lib-crate.
This PR solves this by introducing a side-channel - we just store fs
watchers for abs paths at the Project level. Worktree changes handling
is left relatively untouched - as it's used for other changes besides
LSP change notifying, I've figured to better leave it as is, as right
now we have 1 worktree change watcher; if we were to change it, we'd
have `(language server) + 1` watchers per worktree, which seems.. pretty
horrid.
What's the end effect? At the very least fasterthanlime should be a tad
happier; in reality though, I expect it to have some impact on LS
reliability in monorepo setups.
TODO
- [x] Wire through FileChangeType into `fs::watch` interface.
Release Notes:
- Improved language server reliability in multi-worktree projects and
monorepo. We now notify the language server more reliably about which
files have changed.
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
At the moment Zed is handled as default file browser which causes
applications like RustRover to open Zed when instead it should open the
Gnome files app. And Zed is probably not intended to be an replacement
to the Gnome files app for example.
I'm also currently waiting to fix the issue that Zed is not displayed as
an "Application" when using "Open with..." on Arch Linux. Which is
caused by not setting `APP_ARGS` which should have the value `%F`
Release Notes:
- Fixed: Zed will no longer be handled as default file browser
Release Notes:
- N/A
This updates the IME position every time the selection changes, this is
probably only useful when you enumerate languages with your IME.
TODO:
- ~There is a rare chance that the ime panel is not updated because the
window input handler is None.~
- ~Update IME panel in vim mode.~
- ~Update IME panel when leaving Buffer search input.~
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Closes#15826Closes#16068
When launching zed from the command line, the path parsing prefixes with
`\\?\`. Some LSP servers do not support this type of path, so here I
just simply remove the prefix.
Release Notes:
- N/A
Depending on a number of CPU cores llvmpipe could provide adequate
performance.
A little bit of help to skip searching Zed codebase for solution.
Release Notes:
- N/A
This PR implements a single instance mechanism using the `CreateEventW`
function to create a mutex. If the identifier name begins with `Local`,
the single instance applies only to processes under the same user. If
the identifier begins with `Global`, it applies to all users.
Additionally, I was thinking that perhaps we should integrate the single
instance functionality into `gpui`. I believe applications developed
using `gpui` would benefit from this feature. Furthermore, incorporating
the single instance implementation into `gpui` would facilitate the
`set_dock_menu` functionality. As I mentioned in #12068, the
implementation of `set_dock_menu` on Windows depends on the single
instance feature. When a user clicks the "dock menu", Windows will open
a new application instance. To achieve behavior similar to macOS, we
need to prevent the new instance from launching and instead pass the
parameters to the existing instance.
Any advice and suggestions are welcome.
https://github.com/user-attachments/assets/c46f7e92-4411-4fa9-830e-383798a9dd93
Release Notes:
- N/A
This PR puts the `zed: open account settings` action behind the
`zed-pro` feature flag, as it isn't supposed to be visible to users yet.
Closes https://github.com/zed-industries/zed/issues/17010.
Release Notes:
- N/A
