When neither is specified, if you open a directory you get a new
workspace, otherwise files are added to your existing workspace.
With --new files are always opened in a new workspace
With --add directories are always added to an existing workspace
Fixes#9076Fixes#4861Fixes#5370
Release Notes:
- Added `-n/--new` and `-a/--add` to the zed CLI. When neither is
specified, if you open a directory you get a new workspace, otherwise
files are added to your existing workspace. With `--new` files are
always opened in a new workspace, with `--add` directories are always
added to an existing workspace.
([#9076](https://github.com/zed-industries/zed/issues/9096),
[#4861](https://github.com/zed-industries/zed/issues/4861),
[#5370](https://github.com/zed-industries/zed/issues/5370)).
This fixes#8072 and #9061 by surfacing formatting errors in the
activity indicator.
It shows a message in the activity indicator if the last attempt
to format a buffer failed.
It only keeps track of the last attempt, so any further formatting
that succeeds will reset or update the error message.
I chose to only keep track of that, because everything else (keeping
track of formatting state per buffer, per project, per worktree) seems
complicated with little benefit, since we'd have to keep track of that
state, update it, clean it, etc.
We can still do that should we decide that we need to keep track
of the state on a per-buffer basis, but I think for now this is a
good, simple solution.
This also changes the `OpenLog` action to scroll to the end of the
buffer
and to not mark the buffer as dirty.
Release Notes:
- Added message to activity indicator if last attempt to format a buffer
failed. Message will get reset when next formatting succeeds. Clicking
on message opens log with more information.
([#8072](https://github.com/zed-industries/zed/issues/8072) and
[#9061](https://github.com/zed-industries/zed/issues/9061)).
- Changed `zed: Open Log` action to not mark the opened log file as
dirty and to always scroll to the bottom of the log.
https://github.com/zed-industries/zed/assets/1185253/951fb9ac-8b8b-483a-a46d-712e52878a4d
If a language server would send us a glob pattern like `**/*.rb` or
`**/{package.json}` we'd end up ignoring it and never sending the
language server any notifications, because we try to `strip_prefix` the
projects absolute path from the pattern, BUT if that path is not in the
pattern, we'd return `None`.
This change fixes that.
Release Notes:
- Fixed language server glob patterns for file watching being ignored if
they were relative patterns.
Co-authored-by: Bennet <bennetbo@gmx.de>
Co-authored-by: Remco <djsmits12@gmail.com>
This is just a refactor. I noticed that we now have a `project_core`
crate, which mainly contains the `Worktree` type and its private
helpers, plus the project's settings.
In this PR, I've renamed that crate to `worktree` and did some minor
simplification to its module structure. I also extracted a new
`WorktreeSettings` settings type from the `ProjectSettings`, so that the
worktree settings could live in the worktree crate. This way, the crate
is now exclusively about worktree logic.
Release Notes:
- N/A
This fixes#8896 by storing the `watched_paths` in a separate HashMap,
allowing us to handle the request even before we mark the language
server as running.
Downside is that we have yet another data structure for language
servers, but it also makes the `Running` enum case a bit smaller.
And it fixes the race condition.
Release Notes:
- Fixed language servers not being notified of file changes if language
server registers for file-notification right after starting up.
([#8896](https://github.com/zed-industries/zed/issues/8896)).
Co-authored-by: Bennet <bennetbo@gmx.de>
Co-authored-by: Remco <djsmits12@gmail.com>
This avoids us potentially executing code (if someone were to name their
directory `$(echo you-are-pwned > /secure-files)`, for example).
Works with zsh, bash, fish, nushell. Tested locally with all of them.
Release Notes:
- N/A
In this PR, we've added two new methods that LSP extensions can call:
* `shell_env()`, for retrieving the environment variables set in the
user's default shell in the worktree
* `which(command)`, for looking up paths to an executable (accounting
for the user's shell env in the worktree)
To test this out, we moved the `uiua` language support into an
extension. We went ahead and removed the built-in support, since this
language is extremely obscure. Sorry @mikayla-maki. To continue coding
in Uiua in Zed, for now you can `Add Dev Extension` from the extensions
pane, and select the `extensions/uiua` directory in the Zed repo. Very
soon, we'll support publishing these extensions so that you'll be able
to just install it normally.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
This PR provides WASM extensions with write access to their own specific
working directory under the Zed `extensions` dir. This directory is set
as the extensions `current_dir` when they run. Extensions can return
relative paths from the `Extension::language_server_command` method, and
those relative paths will be interpreted relative to this working dir.
With this functionality, most language servers that we currently build
into zed can be installed using extensions.
Release Notes:
- N/A
We'll send at least one every 100ms, but may send more if other messages
are sent on the connection.
Release Notes:
- Fixed some slowness when collaborating with verbose language servers.
Fixes a regression introduced in
https://github.com/zed-industries/zed/pull/8846 (which hasn't yet been
released), in which the project panel didn't update correctly for remote
projects when collaborating.
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/8874 and
https://github.com/zed-industries/zed/pull/7635
Closes https://github.com/zed-industries/zed/issues/7609
* mentions all `lsp::CodeActions` properties in the Zed client resolve
capabilities to remove more json out of general actions request
potentially
* removes odd `CodeActions.data` field checks, as that field is opaque
and is intended to store data, needed by the langserver to resolve this
code action
* if any `CodeAction` lacks either `command` or `edits` fields, tries to
resolve the action
This all effectively causes Zed to always fire an action resolve
request, since we update actions list (replacing the resolved actions
with the new, unresolved ones) via `refresh_code_actions`
9e66d48ccd/crates/editor/src/editor.rs (L3650)
that is being called on selections change and the actions menu open.
Yet, we do not query the resolve until the action is either applied
(selected in the list), or called for formatting, so it seems to be fine
to resolve them always, as it's not a frequent operation such as
reacting to every keystroke.
Release Notes:
- Fixed certain code actions not being resolved properly ([7609](https://github.com/zed-industries/zed/issues/7609))
---------
Co-authored-by: Derrick Laird <swampdonk@gmail.com>
Previously this code would call `project.visible_worktrees(cx).next`
which might not necessarily return the worktree matching the currently
open file.
What this change does is it adds `get_repo` method on `Project` that
allows us to get the `GitRepository` for the current buffer.
Release Notes:
- Fixed `open permalink to line` not working when multiple folders are
added to the project.
Co-authored-by: Mikayla <mikayla@zed.dev>
Release Notes:
- Fixed detection of `direnv` not working in `fish` when an LSP adapter
(`gopls`, for example) tries to detect user-installed binaries. (#8633)
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
This PR adds **internal** ability to run arbitrary language servers via
WebAssembly extensions. The functionality isn't exposed yet - we're just
landing this in this early state because there have been a lot of
changes to the `LspAdapter` trait, and other language server logic.
## Next steps
* Currently, wasm extensions can only define how to *install* and run a
language server, they can't yet implement the other LSP adapter methods,
such as formatting completion labels and workspace symbols.
* We don't have an automatic way to install or develop these types of
extensions
* We don't have a way to package these types of extensions in our
extensions repo, to make them available via our extensions API.
* The Rust extension API crate, `zed-extension-api` has not yet been
published to crates.io, because we still consider the API a work in
progress.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR does two things to fix
https://github.com/zed-industries/zed/issues/4325:
1. It changes the way `code_actions_on_format` works to send the
possibly configured code actions to _all_ (and not just the primary)
languages servers. That means configured code actions can now be sent to
ESLint, tailwind, ... and other language servers.
2. It enables `codeActionsOnSave` by default for ESLint. That does
**not** mean that by default we will run something on save, but only
that we enable it for ESLint.
Users can then configure their Zed to run the `eslint` code action on
format. Example, for JavaScript:
```json
{
"languages": {
"JavaScript": {
"code_actions_on_format": {
"source.fixAll.eslint": true
}
},
}
}
```
Release Notes:
- Added ability to run ESLint fixes when formatting a buffer. Code
actions configured in
[`code_actions_on_format`](https://zed.dev/docs/configuring-zed#code-actions-on-format)
are now being sent to _all_ language servers connected to a buffer, not
just the primary one. So if a user now sets `"code_actions_on_format": {
"source.fixAll.eslint": true }` in their Zed settings, the
`source.fixAll.eslint` code action will be sent to ESLint, which is not
a primary language server. Since the formatter (prettier, or external
commands, or another language server, ...) still runs, it's important
that these code actions and the formatter don't clash.
([#4325](https://github.com/zed-industries/zed/issues/4325)).
Demo:
https://github.com/zed-industries/zed/assets/1185253/9ef03ad5-1f5c-4d46-b72a-eef611e32f39
I don't think there's value in retrying 4 times as fast as possible,
especially if we might hit the Github API every time to check for the
newest version.
That gets us in rate limit problems quickly.
Release Notes:
- N/A
After a lot of back-and-forth, this is a small attempt to implement
solutions (1) and (3) in
https://github.com/zed-industries/zed/issues/7902. The goal is to have a
minimal change that helps users get started with Zed, until we have
extensions ready.
Release Notes:
- Added detection of user-installed `gopls` to Go language server
adapter. If a user has `gopls` in `$PATH` when opening a worktree, it
will be used.
- Added detection of user-installed `zls` to Zig language server
adapter. If a user has `zls` in `$PATH` when opening a worktree, it will
be used.
Example:
I don't have `go` installed globally, but I do have `gopls`:
```
~ $ which go
go not found
~ $ which gopls
/Users/thorstenball/code/go/bin/gopls
```
But I do have `go` in a project's directory:
```
~/tmp/go-testing φ which go
/Users/thorstenball/.local/share/mise/installs/go/1.21.5/go/bin/go
~/tmp/go-testing φ which gopls
/Users/thorstenball/code/go/bin/gopls
```
With current Zed when I run `zed ~/tmp/go-testing`, I'd get the dreaded
error:
But with the changes in this PR, it works:
```
[2024-02-23T11:14:42+01:00 INFO language::language_registry] starting language server "gopls", path: "/Users/thorstenball/tmp/go-testing", id: 1
[2024-02-23T11:14:42+01:00 INFO language::language_registry] found user-installed language server for Go. path: "/Users/thorstenball/code/go/bin/gopls", arguments: ["-mode=stdio"]
[2024-02-23T11:14:42+01:00 INFO lsp] starting language server. binary path: "/Users/thorstenball/code/go/bin/gopls", working directory: "/Users/thorstenball/tmp/go-testing", args: ["-mode=stdio"]
```
---------
Co-authored-by: Antonio <antonio@zed.dev>
This PR adds a `SystemClock` trait for abstracting away the system
clock.
This allows us to swap out the real system clock with a
`FakeSystemClock` in the tests, thus allowing the fake passage of time.
We're using this in `Telemetry` to better mock the clock for testing
purposes.
Release Notes:
- N/A
Part of #7108
This PR includes just the static runnables part. We went with **not**
having a dedicated panel for runnables.
This is just a 1st PR out of N, as we want to start exploring the
dynamic runnables front. Still, all that work is going to happen once
this gets merged.
Release Notes:
- Added initial, static Runnables support to Zed. Such runnables are defined in
`runnables.json` file (accessible via `zed: open runnables` action) and
they can be spawned with `runnables: spawn` action.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Pitor <pitor@zed.dev>
Co-authored-by: Beniamin <beniamin@zagan.be>
This lets Go programmers configure `"code_actions_on_format": {
"source.organizeImports": true,
}` so that they don't have to manage their imports manually
I landed on `code_actions_on_format` instead of `code_actions_on_save`
(the
VSCode version of this) because I want to run these when I explicitly
format
(and not if `format_on_save` is disabled).
Co-Authored-By: Thorsten <thorsten@zed.dev>
Release Notes:
- Added `"code_actions_on_format"` to control additional formatting
steps on format/save
([#5232](https://github.com/zed-industries/zed/issues/5232)).
- Added a `"code_actions_on_format"` of `"source.organizeImports"` for
Go ([#4886](https://github.com/zed-industries/zed/issues/4886)).
Co-authored-by: Thorsten <thorsten@zed.dev>
Current limitations:
* Not able to navigate into JAR files
Release Notes:
- Added Clojure language support
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Previously we only looked at the global settings, this changes that to
start looking in local settings first and then fall back to global ones.
Fixes#4279.
Release Notes:
- Fixed language server configurations not being picked up from local,
worktree-specific settings.
([#4279](https://github.com/zed-industries/zed/issues/4279)).
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
