Fix a bug where a GPUI macro still used `ModelContext`
Rename `AsyncAppContext` -> `AsyncApp`
Rename update_model, read_model, insert_model, and reserve_model to
update_entity, read_entity, insert_entity, and reserve_entity
Release Notes:
- N/A
Part of https://github.com/zed-industries/zed/issues/22606
Before, `tsdk_path` for vtsls and typescript-language-server
unconditionally set a `tsdk`/`tsserver` property for the corresponding
language server, even if there were no such directory at all.
Instead, make the corresponding code to omit such property if it was not
found on the FS.
Release Notes:
- Fixed "The path /.../tsserver.js doesn't point to a valid tsserver
install. Falling back to bundled TypeScript version." pop-up appearing
This message has confused me many times too: we printed the status as
"Downloading" when we were only checking whether we need to install a
given version of a language server.
This fixes the issue for Node-based language servers where we had the
same check in all implementations.
Closes #22241
Release Notes:
- Fixed some language servers reporting status as "Downloading..." when
only a version check was being done.
This addresses this comment:
https://github.com/zed-industries/zed/pull/13923#issuecomment-2467213210
With the change in here it's now possible to use the following settings:
```json
{
"lsp": {
"tailwindcss-language-server": {
"settings": {
"rootFontSize": 50
}
}
}
}
```
Closes https://github.com/zed-industries/zed/issues/10840
Release Notes:
- Added ability to configure `rootFontSize` for the
`tailwindcss-language-server`. Example settings: `{"lsp":
{"tailwindcss-language-server": {"settings": { "rootFontSize": 50}}}}`
Co-authored-by: Bennet <bennet@zed.dev>
This fixes the issue of multiple language servers showing up as `node`
in the language server logs dropdown.
It does this by changing `language_server.name()` to return the
adapter's name, not the binary name, and changing types to make sure
that we always use this.
Release Notes:
- Fixed language server names showing up only as `"node"`
---------
Co-authored-by: Sam Rose <hello@samwho.dev>
Co-authored-by: Bennet <bennet@zed.dev>
This PR adds support for selecting toolchains for a given language (e.g.
Rust toolchains or Python virtual environments) with support for SSH
projects provided out of the box. For Python we piggy-back off of
[PET](https://github.com/microsoft/python-environment-tools), a library
maintained by Microsoft.
Closes#16421Closes#7646
Release Notes:
- Added toolchain selector to the status bar (with initial support for
Python virtual environments)
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>
This pushes the new LanguageServerName type to more places.
As both languages and language servers were identified by Arc<str>, it
was
sometimes hard to tell which was intended.
Release Notes:
- N/A
Closes#17741
I'm not sure why, but ever since `tailwind` was upgraded to `0.24`,
there have been occasional errors indicating that the `.ps1` file could
not be found. After reviewing the `.ps1` script, it appears that it
simply starts the server using `node`. This PR directly using the method
from the script to start the server with `node`.
Co-authored-by: Anay <me@anayparaswani.dev>
Release Notes:
- N/A
---------
Co-authored-by: Anay <me@anayparaswani.dev>
Release Notes:
- Changed built-in language support (Rust, Go, C, YAML, ...) to lookup
language-server specific settings locally in project directory first
before falling back to global value.
---------
Co-authored-by: Bennet <bennet@zed.dev>
Closes#15441 .
Fixed the issue where extensions couldn't start if the path contained
spaces. Additionally, this PR introduces the `node_environment_path`
function to obtain the PATH environment variable which includes the node
path.
Release Notes:
- N/A
This addresses the question in [this
comment](https://github.com/zed-industries/zed/issues/5830#issuecomment-2211942554)
by adding support for `classAttributes` to the settings.
Meaning that the following Zed `settings.json` now works:
```jsonc
{
"lsp": {
"tailwindcss-language-server": {
"settings": {
"classAttributes": [
"class",
"className",
"ngClass",
// add styles so will give intellisense to styles constant.
"styles"
]
// Optional:
// "includeLanguages": {
// "erb": "html",
// "ruby": "html"
// },
// "experimental": {
// "classRegex": ["\\bclass:\\s*['\"]([^'\"]*)['\"]"]
// }
}
}
}
}
```
Release Notes:
- Added support for setting `classAttributes` in the configuration for
`tailwindcss-language-server`. Example: `{ "lsp": {
"tailwindcss-language-server": { "settings": { "classAttributes": [
"class", "className", "ngClass", "styles" ] } } } }`
This adds the ability to configure the `tailwindcss-language-server`
integration to use a custom build of the server.
Example configuration in Zed `settings.json`:
```json
{
"lsp": {
"tailwindcss-language-server": {
"binary": {
"arguments": [
"/Users/username/tailwindcss-intellisense/packages/tailwindcss-language-server/bin/tailwindcss-language-server",
"--stdio"
]
}
}
}
}
```
This will cause Zed to use its own Node version and run it with the
given arguments.
**Note**: you need to provide `--stdio` as the second argument!
It's also possible to use a custom Node binary:
```json
{
"lsp": {
"tailwindcss-language-server": {
"binary": {
"path": "/Users/username/bin/my-node",
"arguments": [
"/Users/username/tailwindcss-intellisense/packages/tailwindcss-language-server/bin/tailwindcss-language-server",
"--stdio"
]
}
}
}
}
```
This is *super handy* when debugging the language server.
Release Notes:
- Added ability to configure own build of `tailwindcss-language-server`
in Zed settings. Example:
`{"lsp":{"tailwindcss-language-server":{"binary":{"arguments":["/absolute/path/to/tailwindcss-language-server/bin/tailwindcss-language-server",
"--stdio" ]}}}}`
This fixes the issue mentioned here:
https://github.com/zed-industries/zed/issues/5830#issuecomment-2111947083
In order for other languages to work, we need to pass the following
settings along to the Tailwind language server.
With the following Zed settings, it then also works for Scala:
```json
{
"languages": {
"Scala": {
"language_servers": ["tailwindcss-language-server"]
},
},
"lsp": {
"tailwindcss-language-server": {
"settings": {
"includeLanguages": {
"scala": "html"
},
"experimental": {
"classRegex": ["[cls|className]\\s\\:\\=\\s\"([^\"]*)"]
}
}
}
}
}
```
Release Notes:
- Added ability to configure settings for `tailwindcss-language-server`,
namely the `includeLanguages` and `experimental` objects.
**NOTE**: I have only tested that the language server boots up for Scala
files and that the settings are forwarded correctly. I don't have a
Scala+Tailwind project with which to test that the actual completions
also work.
cc @nguyenyou
This PR adds the ability for extensions to implement
`language_server_workspace_configuration` to provide workspace
configuration to the language server.
We've used the Dart extension as a motivating example for this, pulling
it out into an extension in the process.
Release Notes:
- Removed built-in support for Dart, in favor of making it available as
an extension. The Dart extension will be suggested for download when you
open a `.dart` file.
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
We're doing it. Svelte support is moving into an extension. This PR
fixes some issues that came up along the way.
Notes
* extensions need to be able to retrieve the path the `node` binary
installed by Zed
* previously we were silently swallowing any errors that occurred while
loading a grammar
* npm commands ran by extensions weren't run in the right directory
* Tree-sitter's WASM stdlib didn't support a C function (`strncmp`)
needed by the Svelte parser's external scanner
* the way that LSP installation status was reported was unnecessarily
complex
Release Notes:
- Removed built-in support for the Svelte and Gleam languages, because
full support for those languages is now available via extensions. These
extensions will be suggested for download when you open a `.svelte` or
`.gleam` file.
---------
Co-authored-by: Marshall <marshall@zed.dev>
Our goal is to extract Svelte support into an extension, since we've
seen problems with the Tree-sitter Svelte parser crashing due to bugs in
the external scanner. In order to do this, we need a couple more
capabilities in LSP extensions:
* [x] `initialization_options` - programmatically controlling the JSON
initialization params sent to the language server
* [x] `prettier_plugins` - statically specifying a list of prettier
plugins that apply for a given language.
* [x] `npm_install_package`
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Fixes: https://github.com/zed-industries/zed/issues/9234
This doesn't address `vue` as it has a slightly different install code,
but it should be fairly simple to add - I'll add it in in a follow-up.
This PR will allow all (except `vue`) node-based language servers to
update. It is mostly just throwing in a method into the `NodeRuntime`
trait that is used for checking if a package doesn't exist locally, or
is out of date, by checking the version against what's newest, and
installing. If any parsing of the `package.json` data fails along the
way, it assumes something has gone awry on the users system, logs the
error, and then proceeds with trying to install the package, so that
users don't get stuck on version if their package has some bad data.
Outside of adding this method, it just adds that check in all of the
language server's individual `fetch_server_binary` methods.
Release Notes:
- Added updating for node-based language servers
([#9234](https://github.com/zed-industries/zed/issues/9234)).
This fixes#9292 by adding a section to the language server settings
that allows users to specify the binary path and arguments with which to
start up a language server.
Example user settings for `rust-analyzer`:
```json
{
"lsp": {
"rust-analyzer": {
"binary": {
"path": "/Users/thorstenball/tmp/rust-analyzer-aarch64-apple-darwin",
"arguments": ["--no-log-buffering"]
}
}
}
}
```
Constraints:
* Right now this only allows ABSOLUTE paths.
* This is only used by `rust-analyzer` integration right now, but the
setting can be used for other language servers. We just need to update
the adapters to also respect that setting.
Release Notes:
- Added ability to specify `rust-analyzer` binary `path` (must be
absolute) and `arguments` in user settings. Example: `{"lsp":
{"rust-analyzer": {"binary": {"path": "/my/abs/path/rust-analyzer",
"arguments": ["--no-log-buffering"] }}}}`
([#9292](https://github.com/zed-industries/zed/issues/9292)).
Co-authored-by: Ricard Mallafre <rikitzzz@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>
- Moves languages module from `zed` into a separate crate. That way we
have less of a long pole at the end of compilation.
- Removes moot dependencies on editor/picker. This is totally harmless
and might help in the future if we decide to decouple picker from
editor.
Before:
```
Number of crates that depend on 'picker' but not on 'editor': 1
Total number of crates that depend on 'picker': 13
Total number of crates that depend on 'editor': 30
```
After:
```
Number of crates that depend on 'picker' but not on 'editor': 5
Total number of crates that depend on 'picker': 12
Total number of crates that depend on 'editor': 26
```
The more crates depend on just picker but not editor, the better in that
case.
Release Notes:
- N/A
2024-02-23 15:56:08 +01:00
Renamed from crates/zed/src/languages/tailwind.rs (Browse further)
