This PR fix the "invalid cross-device link" error occurred in linux when
trying to write the settings file atomically, like when click the
"Enable vim mode" checkbox at first start.
```plain
[2024-02-26T22:59:25+08:00 ERROR util] .../zed/crates/settings/src/settings_file.rs:135: Failed to write settings to file "/home/$USER/.config/zed/settings.json"
Caused by:
0: failed to persist temporary file: Invalid cross-device link (os error 18)
1: Invalid cross-device link (os error 18)
```
Currently the `fs::RealFs::atomic_write()` method write to a temp file
created with `NamedTempFile::new()` and then call `persist()` method to
write to the config file path, which actually do a `rename` syscall
under the hood. As the
[issue](https://github.com/Stebalien/tempfile/issues/245) said
> `NamedTempFile::new()` will create a temporary file in your system's
temporary file directory. You need `NamedTempFile::new_in()`.
The temporary file directory in linux is in `/tmp`, which is mounted to
`tmpfs` filesystem, and in most case(all case I guess)
`$HOME/.config/zed` is mounted to a different filesystem. And the
`rename` syscall between different filesystems will return a `EXDEV`
errno, as described in the man page
[rename(2)](https://man7.org/linux/man-pages/man2/renameat2.2.html):
```plain
EXDEV oldpath and newpath are not on the same mounted
filesystem. (Linux permits a filesystem to be mounted at
multiple points, but rename() does not work across
different mount points, even if the same filesystem is
mounted on both.)
```
And as the issue above said, use a different temp dir with
`NamedTempFile::new_in()` for linux platform might be a solution, since
the `rename` syscall provides atomicity.
Release Notes:
- Fix `settings.json` save failed with invalid cross-device link error
in linux
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 PR cleans up the path definitions in `util::paths` following the
Linux merge.
We were using a bunch of target-specific compilation that made these
declarations kind of messy, when really we can limit the conditional
compilation to just the base directories that we use as the basis for
the other directories.
Release Notes:
- N/A
This PR adds the initial support for loading extensions in Zed.
### Extensions Directory
Extensions are loaded from the extensions directory.
The extensions directory has the following structure:
```
extensions/
installed/
extension-a/
grammars/
languages/
extension-b/
themes/
manifest.json
```
The `manifest.json` file is used internally by Zed to keep track of
which extensions are installed. This file should be maintained
automatically, and shouldn't require any direct interaction with it.
Extensions can provide Tree-sitter grammars, languages, and themes.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
On Windows, `OsStr` must be a valid
[WTF-8](https://simonsapin.github.io/wtf-8/) sequence, and there are no
safety ways converting from bytes to OsStr in std. So I added
`PathExt::try_from_bytes` and use it in `sqlez`.
This PR adds support for loading user themes in Zed.
Themes are loaded from the `themes` directory under the Zed config:
`~/.config/zed/themes`. This directory should contain JSON files
containing a `ThemeFamilyContent`.
Here's an example of the general structure of a theme family file:
```jsonc
{
"name": "Vitesse",
"author": "Anthony Fu",
"themes": [
{
"name": "Vitesse Dark Soft",
"appearance": "dark",
"style": {
"border": "#252525",
// ...
}
}
]
}
```
Themes placed in this directory will be loaded and available in the
theme selector.
Release Notes:
- Added support for loading user themes from `~/.config/zed/themes`.
This PR adds undocumented functionality for loading custom language
plugins at runtime. I don't intend to expose the functionality to end
users yet, but this will allow the team to test the capability
internally.
### Implementation
There isn't much new code in Zed. Most of the work here is within
Tree-sitter, in PRs https://github.com/tree-sitter/tree-sitter/pull/1864
and https://github.com/tree-sitter/tree-sitter/pull/2840, which allow
Tree-sitter to load languages from WASM blobs. I've tested the
functionality in Tree-sitter's test suite and via its CLI, but having it
wired into Zed allows us to test the functionality more fully.
### Details
Now, on startup, Zed will look for subdirectories inside of
`~/Application Support/plugins`. These subdirectories are expected to
look similar to the per-language subdirectories in
[`crates/zed2/src/languages`](https://github.com/zed-industries/zed/tree/main/crates/zed2/src/languages),
except that they also contain a `.wasm` file for the parser itself.
I'll add more details here as I go.
New rustc messages look like
```
thread 'tests::test_history_items_vs_very_good_external_match' panicked at crates/file_finder/src/file_finder.rs:1902:13:
assertion `left == right` failed: Only one history item contains collab_ui, it should be present and others should be filtered out
left: 0
right: 1
```
now and we fail to parse that `13:` bit properly, fix that.
Still need to implement loading / listing.
I'd really be rather write operations to a database. Maybe we
should be auto-saving? Integrating with panes? I just did
the simple thing for now.
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>
