This PR mainlines the current state of new GPUI2-based UI from the
`gpui2-ui` branch.
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Nate <nate@zed.dev>
This is a PR I built for a friend of a friend at StrangeLoop, who is
making a much better LSP for elixir that elixir folks want to experiment
with. This PR also improves the our debug log viewer to handle LSP
restarts.
TODO:
- [ ] Make sure NextLS binary loading works.
Release Notes:
- Added support for the experimental Next LS for Elxir, to enable it add
the following field to your settings to enable:
```json
"elixir": {
"next": "on"
}
```
Targeting Preview of 09.27.
This is still pending several touchups/clearups:
- We should watch multibuffer for changes and rescan the excerpts. This
should also update match count.
- Closing editor while multibuffer with 100's of changed files is open
leads to us prompting for save once per each file in the multibuffer.
One could in theory save in multibuffer before closing it (thus avoiding
unnecessary prompts), but it'd be cool to be able to "Save all"/"Discard
All".
Release Notes:
- Added "Replace in project" functionality
Copilot is being used in every buffer, but we do not see its logs that
easily.
In the future, prettier wrapper will pretend to be an LSP server, it is
better to log its messages somewhere, so prepare an infrastructure for
that.
<img width="1727" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/d31a257c-9608-46fa-8be1-f0a2a2bdbdb7">
Copilot seem to have no rpc messages logged for some reason now,
prettier wrapper might be a better case to investigate this, so leaving
as is.
Release Notes:
- N/A
This is still WIP, mostly pending styling. I added a pretty rudimentary
text field and no buttons whatsoever other than that. I am targeting a
Preview of 09.13, as I am gonna be on PTO for the next week.
I dislike the current implementation slightly because of `regex`'s crate
syntax and lack of support of backreferences. What strikes me as odd wrt
to syntax is that it will just replace a capture name with empty string
if that capture is missing from the regex. While this is perfectly fine
behaviour for conditionally-matched capture groups (e.g. `(foo)?`), I
think it should still error out if there's no group with a given name
(conditional or not).
Release Notes:
- Added "Replace" functionality to buffer search.
In some situations outside JSX elements Tailwind will never
respond to a completion request, holding up the tsserver completions.
Only submit the request to Tailwind when we wouldn't get tsserver
completions anyway and don't submit to Tailwind when we know we won't
get Tailwind completions
Co-Authored-By: Kirill Bulatov <kirill@zed.dev>
See Linear description for the full explanation of the issue. This PR is
mostly a mechanical change, except for the one case where we do pass in
an explicit `next_id` instead of `model_id` in project.rs.
Release Notes:
- Fixed a bug where some results were not reported in project search in
presence of unnamed buffers.
This is the first batch of improvements to current project search. There
are few things we can do better still, but I want to get this out in
next Preview.
Most of the slowness at this point seems to stem from updating UI too
often.
Release Notes:
- Improved project search by making it report results sooner.
---------
Co-authored-by: Julia Risley <julia@zed.dev>
Use word_characters to feed completion trigger characters as well and
also recognize kebab as a potential sub-word splitter. This is fine for
non-kebab-case languages because we'd only ever attempt to split a word
with a kebab in it in language scopes which are kebab-cased
Co-Authored-By: Max Brunsfeld <max@zed.dev>
This isn't ready to go - I'm opening a PR to ask for some advice. When
activating a python virtual environment, the typical command used is
`source path_to_venv/bin/activate`. The problem is, the activatate
script isn't portable to all shells, so some additional scripts are
bundled in the env, for example, `activate.fish`. We don't have a good
way of knowing what shell we are in, in order to know what script to
run.
Julia gave the alternative of simply activating the virtual environment
while in the zsh context, before the user's custom shell is launched,
which I think does work, but because we activate the virtual environment
before we launch the custom shell, the shell isn't really aware that we
are in the virtual environment and it fails to display the information
in the prompt that is typically shown after activating.
Is there a clean way for us to know for a fact what shell is being ran,
so we know what script to run?
Check out the code comments below for more context.
---
https://github.com/zed-industries/zed/assets/19867440/ddb76aaa-152b-4c93-a513-3cd580b7c40f
I've used Zed to write Python scripts, but working on an actual project
has really magnified where Python dev is falling short. A huge
quality-of-life thing we can do is provide a setting to automaticaly
search for and activate virtual environments when found, when terminals
are created. Manually starting these up in every terminal instance is
such a drag.
A few quirks:
- We don't have a way of knowing if the prompt is ready before we try
run the command, which means we see the text inserted at the top of the
terminal and on the prompt - I dont think this should be a blocker
though.
- If a user has multiple python projects with mutliple virtual
environments, we only detect and activate the first one, since can't
really make any assumptions about which one to activate. I dont think
this should be a blocker either, as I think most users will have a
single project open in Zed.
Release Notes:
- Added a `detect_venv` setting for the terminal. When configured, the
Zed terminal will automatically activate Python virtual environments on
terminal creation.
Without holding all hints in host's cache, this is impossile.
Currenly, we keep hint caches separate and isolated, so this will not
work when we actually resolve.
This PR adds new config option to language config called
`word_boundaries` that controls which characters should be recognised as
word boundary for a given language. This will improve our UX for
languages such as PHP and Tailwind.
Release Notes:
- Improved completions for PHP
[#1820](https://github.com/zed-industries/community/issues/1820)
---------
Co-authored-by: Julia Risley <julia@zed.dev>
This PR adds new config option to language config called
`word_boundaries` that controls which characters should be recognised as
word boundary for a given language. This will improve our UX for
languages such as PHP and Tailwind.
Release Notes:
- Improved completions for PHP
[#1820](https://github.com/zed-industries/community/issues/1820)
---------
Co-authored-by: Julia Risley <julia@zed.dev>
Tailwind likes to throw a lot of completion data at us, this gets it to
send less. Previously it would respond to a completion with 2.5 MB JSON
blob, now it is more like 0.8 MB.
Relies on a local copy of lsp-types with the `itemDefaults` field added.
I don't have write perms to push to our fork of the crate atm, sorry :)
Follow-up to https://github.com/zed-industries/zed/pull/2777
Refs https://github.com/zed-industries/community/issues/1770
In this PR, I reworked the way that git statuses are retrieved. In a
huge repository like `WebKit`, the really slow part of computing a list
of git statuses is the *unstaged* portion of the diff. For the *staged*
diff, `git` can avoid comparing the contents of unchanged directories,
because the index contains hashes of every tree. But for the *unstaged*
portion, Git needs to compare every file in the worktree against the
index. In the common case, when there are no changes, it's enough to
check the `mtime` of every file (because the index stores the mtimes of
files when they are added). But this still requires an `lstat` call to
retrieve each file's metadata.
I realized that this is redundant work, because the worktree is
*already* calling `lstat` on every file, and caching their metadata. So
in this PR, I've changed the `Repository` API so that there are separate
methods for retrieving a file's *staged* and *unstaged* statuses. The
*staged* statuses are retrieved in one giant batch, like before, to
reduce our git calls (which also have an inherent cost). But the
`unstaged` statuses are retrieved one-by-one, after we load files'
mtimes. Often, all that's required is an index lookup, and an mtime
comparison.
With this optimization, it once again becomes pretty responsive to open
`WebKit` or `chromium` in Zed.
Release Notes:
- Optimized the loading of project file when working in very large git
repositories
Deals with https://github.com/zed-industries/community/issues/752
Deals with https://github.com/zed-industries/community/issues/566
Currently, when converting from LSP to Zed objects, completions with
non-empty `additional_text_edits` are filtered out.
Later, all other completions form a list and the selected one gets the
`Editor::confirm_completion` call, which always queries an LSP
completion resolve request to get the `additional_text_edits` field.
Otherwise, `additional_text_edits` field is ignored entirely for the
rest of the completion lifetime — and we always pass the selected
completion through the resolve request.
The PR changes the logic, removing the `additional_text_edits` filtering
and instead of resolving every completion, now we check for
`additional_text_edits` in the completion before resolving: resolve
happens only if the data is absent.
Generally, feels like resolve has to happen before the completion
selection: LSP servers may send us markdown for completion documentation
preview pop ups and similar extra info.
Also, the server may lack resolve capabilities entirely, always sending
the request seems dangerous.
For now, the PR does not attempt to change either.
Release Notes:
- Brings rust-analyzer's postfix completions and others completions with
preresolved additional text edits
Instead of storing `initialization_options` in every LSP adapter as
before, store previous LSP settings in `Project` entirely.
This way, we can later have use multiple different project
configurations per single LSP with its associated adapter.
co-authored-by: Max Brunsfeld <max@zed.dev>
Language servers mixed `initialization_options` from hardcodes and user
settings, fix that to ensure we restart servers on their settings
changes only.
Language servers such as typescript-language-servers report a single
work event, ending right after server's startup.
Other servers might send more similar event, also during startup.
The rest of the events are diagnostic-related and we filter them out.
React on such events with /refresh-like hint update, that will check
only the visible part of the editor for hints and might be replaced by
other /refresh requests, if needed.
As part of an optimization in
https://github.com/zed-industries/zed/pull/2663, I changed the way that
the worktree ignores FS events within unloaded directories. But this
accidentally prevented us from detecting some events that occur inside
of `.git` directories.
In this PR, I've made further tweaks to which FS events we can ignore.
We now explicitly opt *in* to scanning `.git` (shallowly) directories
(even though they are ignored). Note that we still don't recursively
scan the git directory (including all of the files inside `objects`
etc). This seems like the correct amount of work to do, and from my
testing (and our unit tests that use the real FS and real git
repositories), it seems to work correctly.
Release Notes:
- Fixed a bug where Zed would not detect some git repository changes
(preview only).
These adapters have indicated some broader reason to the user why
they cannot be started, don't waste time/bandwidth attempting to
validate and reinstall them
Don't wait until populating that directory entry, for two reasons:
* In the case of submodules, .git is not a directory
* We don't eagerly populate .git directories, since their contents
are automatically ignored.
This PR allows you to customize Zed's settings within a particular
folder by creating a `.zed/settings.json` file within that folder.
Todo
* [x] respect folder-specific settings for local projects
* [x] respect folder-specific settings in remote projects
* [x] pass a path when retrieving editor/language settings
* [x] pass a path when retrieving copilot settings
* [ ] update the `Setting` trait to make it clear which types of
settings are locally overridable
Release Notes:
* Added support for folder-specific settings. You can customize Zed's
settings within a particular folder by creating a `.zed` directory and a
`.zed/settings.json` file within that folder.
This PR makes the worktree's change events more useful in a few ways:
* The changes are now described by a cheaply clone-able collection, so
that they can be used in background tasks. Right now, I'm using a simple
Arc slice.
* The `UpdatedEntries` event now captures not only changes due to FS
changes, but also newly-loaded paths that are discovered during the
initial scan.
* The `UpdatedGitRepositories` event now includes repositories whose
work-dir changed but git dir didn't change. A boolean flag is included,
to indicate whether the git content changed.
* The `UpdatedEntries` and `UpdatedGitRepositories` events are now
*used* to compute the worktree's `UpdateWorktree` messages, used to sync
changes to guests. This unifies two closely-related code paths, and
makes the host more efficient when collaborating, because the
`UpdateWorktree` message computation used to require walking the entire
`entries` tree on every FS change.
We don't need to look-up change types by an arbitrary key, but we
do need to iterate it. It would also be useful to be able to
cheaply clone the changes, to use them in a background task.
This avoids an issue where in a many-buffer multi-buffer, each modified
buffer could complete its recalc independently, causing a cascade of
repeated notifies
Now all recalcs started at the same time must complete before
A: Starting another recalc pass
B: The master notify occurring
Each buffer can still show its new diff if something else triggers it
to notify earlier, this is desirable and does not have the same negative
effects as the notify cascade as those re-layouts would need to happen
anyway
Co-Authored-By: Max Brunsfeld <max@zed.dev>
This PR fixes a bug in the firing of the UpdatedRepositories event which
caused it to flood collaboration with new messages on every file save.
Release Notes:
* Fixed a bug in repository detection that caused it to fire
over-eagerly (preview only)
Fixes a bug introduced in
https://github.com/zed-industries/zed/pull/2448, where error messages
would be logged if the user config didn't specify certain fields like
`journal` or `telemetry`.
Deals with https://github.com/zed-industries/community/issues/179 by
sending a message about it, to asynchronously apply on all workspaces.
Release Notes:
* Fixes a bug when files, deleted in the project panel were left open in
the editor
* Convert globs to relative paths in advance. This avoids needing to convert
every changed path to an absolute path before performing glob matching.
* Avoid duplicate reporting for language servers with multiple worktrees.
This commit introduces a new adaptor trait for SeekTarget that works around
frustrating issues with lifetimes. It wraps the arguments in a newtype wrapper
that lives on the stack to avoid the lifetime getting extended to the caller
of the method.
This allows us to introduce a PathSuccessor object that can be passed as the
end argument of remove_between to remove a whole subtree.
Added branches to the randomized test to check the git branch
Added the remaining database integrations in collab
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Petros <petros@zed.dev>
The scan_id needs to be bumped even if a scan is already in progress,
so that worktree updates can detect that entries have changed. This
means that the worktree's completed_scan_id may increase by more than
one at the end of a scan.
Previously, we could end up with a situation where the host did not
see an operation but a guest that didn't have that buffer open would. When
such guest would finally open the buffer, they would apply the operation
without however sending it to the host. The guest wouldn't bother resyncing
it because it wasn't part of its open buffers.
Previously, if the client was disconnected while the initial worktree
state was being sent, it would not see the remaining state after reconnecting.
This was due to `scan_id` and `completed_scan_id` both being initialized to
`0`, so the client would ask for updates since `0` and get nothing.
This commit changes the worktree to initialize `scan_id` to `1` and
`completed_scan_id` to `0`, so that we get the full worktree again on reconnect.
Previously, because UpdateProject messages were sent in a separately-
spawned task, they could be sent after CreateBufferForPeer messages that
were intended to be sent after them.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
In `refresh_entry`, we send a message to the `self.path_changes_tx` channel
to notify the background thread that a path has changed. However, given that
`refresh_entry` uses `spawn_weak`, the worktree could get dropped before sending
the message, which could cause a panic.
This commit changes the code to return an error instead of panicking.
Check if the buffer already exists *before* overwriting it.
Ignore redundant registrations on remote projects.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
This fixes a bug where the host would momentarily disconnect and the guest
would close and reopen the project. This would cause the host to not observe
the guest closing the project. When the guest tried to open one of the
buffers opened prior to closing the project, the host would not send them the
buffer state because it would still remember that the buffer was shared.
The `shared_buffers` map is now cleared when the host reconnects and will slowly
get re-filled as guests issue `SynchronizeBuffers` requests.
Refactor HTTP and github release downloading into util
Lazily download / upgrade the copilot LSP from Zed
Co-authored-by: Max <max@zed.dev>
Co-Authored-By: Antonio <antonio@zed.dev>
The worktree no longer pulls the background snapshot from the background scanner.
Instead, the background scanner sends both snapshots to the worktree. Along with
these, it sends the path change sets.
Also, add randomized test coverage for the worktree UpdatedEntries events.
* Consolidate local worktree construction into one method
* Simplify remote worktree construction
* Reduce indirection around pulling worktree snapshots from the background
Previously, we would simulate disk-based diagnostics finishing after
saving a buffer. However, the language server may produce diagnostics
right after emitting the event, causing the diagnostics status bar item
to not reflect the latest state of the buffer.
With this change, we will instead simulate disk-based diagnostics finishing
after 1s after saving the buffer (only for language servers that
don't have the concept of disk-based diagnostics, such as TypeScript). This
ensures we always reflect the latest state and doesn't cause the UI to flicker
as a result of the LSP sending us diagnostics after every input.
If the host thinks a guest has a buffer that they don't have, the host won't
send it to them when they attempt to open it the next time. This can happen
if the guest disconnected before they received the host's response to an
initial open buffer request.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Any buffers we requested but that haven't been fully sent will cause
outstainding open requests to hang. If we re-request them, any
waiting open requests will resume when the requested buffers finish
being created.
Co-authored-by: Max Brunsfeld <max@zed.dev>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
It's possible that the host was disconnected when attempting to notify
guests of a file save, so we need to transmit this in order to correctly
update the file's mtime.
Next failing seed OPERATIONS=200 SEED=6894
We need to know the most recent scan id we have actually completed. This is to
handle the case where a guest disconnects when we're in the middle of streaming
worktree entries to them. When they reconnect, they need to report a scan_id
from before we started streaming the entries, because we have no record of when
the stream was interrupted.
Next failure:
SEED=5051 ITERATIONS=1 OPERATIONS=200 cargo test --release --package=collab random -- --nocapture
When a host sends a buffer to a guest for the first time, they record that
they have done so in a set tied to that guest's peer id. When the guest
reconnects and syncs buffers, they do so under a different peer id, so we
need to be sure we track which buffers we have sent them to avoid sending
them the same buffer twice, which violates the guest's assumptions.
Also, construct remote projects via the room, to guarantee
that the room can manage the projects' sharing lifecycle.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>