This PR needs suggestions, especially from the Zed team. As I mentioned
in a previous issue #13394 , the `vscode-json-languageserver` that Zed
originally relied on has some issues with JSON schema validation on
Windows, and it hasn't been updated for a long time. This PR uses the
more frequently updated `vscode-langservers-extracted`, which resolves
this issue.
Currently, `vscode-langservers-extracted` includes not only the JSON LSP
server but also LSP servers for other languages. I think we might need a
package specifically for the JSON LSP server, such as something like
`vscode-json-langserver-extracted`, or we could consider using the LSP
servers for other languages from this package as well.
And, there are some issues with installing
`vscode-langservers-extracted` on Windows, causing the `postinstall`
script to fail. However, this does not seem to affect any functionality.
Therefore, I think the best solution is for the Zed team to maintain a
package like `vscode-json-langserver-extracted` or something else. This
way, we can update it promptly and address the installation issues on
Windows.
Any suggestions or advices are welcome.
#### JSON vaildation on Winodws
https://github.com/zed-industries/zed/assets/14981363/8cd7ff54-28ec-4601-b2e5-183e2fae2051Closes#13394
Release Notes:
- Fixed JSON schema validation issue on Windows.(#13394 )
This makes us treat yaml like other indentation-sensitive languages
(e.g. Python) and not reformat it on pasting and what not.
Fixes#12236Fixes#13338
Release Notes:
- Fixed spurious appliance of auto-formatting to YAML blocks.
Additionally, limit # of returned completion items + use fuzzy filtering
on VTSLS side. Prime LSP handler for response handling.
Release Notes:
- VTSLS is now a default language server for TypeScript, TSX, and
JavaScript.
This PR replaces the `lazy_static!` usages in the `paths` crate with
`OnceLock` from the standard library.
This allows us to drop the `lazy_static` dependency from this crate.
The paths are now exposed as accessor functions that reference a private
static value.
Release Notes:
- N/A
This PR extracts the definition of the various Zed paths out of `util`
and into a new `paths` crate.
`util` is for generic utils, while these paths are Zed-specific. For
instance, `gpui` depends on `util`, and it shouldn't have knowledge of
these paths, since they are only used by Zed.
Release Notes:
- N/A
Some of the runnables added in #12118 don't work for tests (or code)
that contain spaces. In other words, the runnable for a test like
```js
it('does the thing', () => ...)
```
would end up w/ something like `npx jest does the thing
/path/to/file.spec.js`, but what we really want is `npx jest
--testNamePattern "does the thing" /path/to/file.spec.js`. A similar
thing was happening for the "node execute selection" runnable: selecting
`let foo = 1` would run `node -e let foo = 1`, not `node -e "let foo =
1"`.
In my (somewhat limited?) experience, it's very common for tests like
these to include spaces, and of course a code selection is almost
certain to contain whitespace.
Not covered:
- this just blindly wraps quotes around the symbol/code; in the future
it may make sense to try to figure out *what type of quote* to use. (eg
`it('does the "thing"', () => ...)` is a valid test name, but
`--testNamePattern "does the "thing""` would not work. Note the doubled
quotes.)
- I did not wrap the filenames in quotes to escape those for the shell,
nor did I test if that's actually an issue. In my experience, I've not
seen many (any?) test files that contain spaces in the name, but I
suspect that it would be an issue if a containing dir includes spaces.
(eg `npx jest ... /path/to/My Documents/Code/file.spec.js`
/cc @RemcoSmitsDev
Release Notes:
- Fixed some runnables in Javascript/Typescript
Fix#12884
Release Notes:
- Added runnable tests for TSX files.
---
Runnable tests can be customized via `tsx-test` tag
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Release Notes:
- Added support for looking up the `rust-analyzer` binary in `$PATH`. This allows using such tools as `asdf` and nix to configure per-folder rust installations. To enable this behavior, use the `path_lookup` key when configuring the `rust-analyzer` `binary`: `{"lsp": {"rust-analyzer": {"binary": {"path_lookup": true }}}}`.
Fixes case when `package.json` is not in root directory.
Usually in mono repository, where multiple `package.json` may be present
Release Notes:
- Fixed runnable for package.json in monorepos
This PR adds default settings to disable `vtsls` by default so that
there aren't multiple TypeScript language servers running.
I also renamed the language server from `vtsls-language-server` to just
`vtsls`, since the `-language-server` suffix was redundant.
Release Notes:
- N/A
You can opt into using VTSLS instead of typescript-language-server by
pasting the following snippet into your settings:
```
"languages": {
"TSX": {
"language_servers": [
"!typescript-language-server",
"vtsls-language-server"
]
}
},
```
Related to: #5166
Release Notes:
- Added support for using [vtsls](https://github.com/yioneko/vtsls)
language server for Typescript/Javascript.
@mrnugget spotted that tsconfig.json schema is getting applied on
current Nightly. I've tracked it down to a misconfiguration of JSON
language server. Mea culpa.
No release note as that change has not went out to the public yet.
Release Notes:
- N/A
Add runnable tasks for Python, starting with `unittest` from the
standard library. Both `TestCase`s (classes meant to be a unit of
testing) and individual test functions in a `TestCase` will have
runnable icons. For completeness, I also included a task that will run
`unittest` on the current file.
The implementation follows the `unittest` CLI. The unittest module can
be used from the command line to run tests from modules, classes or even
individual test methods:
```
python -m unittest test_module.TestClass
python -m unittest test_module.TestClass.test_method
```
```python
import unittest
class TestStringMethods(unittest.TestCase):
def test_upper(self):
self.assertEqual('foo'.upper(), 'FOO')
def test_isupper(self):
self.assertTrue('FOO'.isupper())
self.assertFalse('Foo'.isupper())
def test_split(self):
s = 'hello world'
self.assertEqual(s.split(), ['hello', 'world'])
# check that s.split fails when the separator is not a string
with self.assertRaises(TypeError):
s.split(2)
if __name__ == '__main__':
unittest.main()
```
From the snippet provided by `unittest` docs, a user may want to run
test_split independently of the other test functions in the test case.
Hence, I decided to make each test function runnable despite `TestCase`s
being the unit of testing.
## Example of running a `TestCase`
<img width="600" alt="image"
src="https://github.com/zed-industries/zed/assets/16619392/7be38b71-9d51-4b44-9840-f819502d600a">
## Example of running a test function in a `TestCase`
<img width="600" alt="image"
src="https://github.com/zed-industries/zed/assets/16619392/f0b6274c-4fa7-424e-a0f5-1dc723842046">
`unittest` will also run the `setUp` and `tearDown` fixtures.
Eventually, I want to add the more commonly used `pytest` runnables
(perhaps as an extension instead).
Release Notes:
- Added runnable tasks for Python `unittest`.
([#12080](https://github.com/zed-industries/zed/issues/12080)).
/cc @RemcoSmitsDev new task indicators weren't showing for me in JSON
files.
`tasks.json` of native grammars is not being read by anything by
default, so we tend to register tasks as Rust structs, foregoing the
deserialization step. This doesn't apply to tasks registered in
extensions, which have to have tasks.json.
Release Notes:
- N/A
Rust recently got the ability to check for typos or errors in `cfg`
attributes: https://blog.rust-lang.org/2024/05/06/check-cfg.html
This PR fixes the new warnings.
- gpui can be run with `RUSTFLAGS="--cfg gles"`, make this explicit in
`[workspace.lints.rust]`
- `cfg!(any(test, sqlite))` was just a bug, it should be
`feature(sqlite)`
- the `languages` crate had a `#[cfg(any(test, feature =
"test-support"))]` function without ever declaring the `test-support`
feature
- the `MarkdownTag` enum had a `cfg_attr` for serde without actually
having serde support
Now the only warnings when building are unused fields
`InlayHover.excerpt`, `SavedConversationMetadata.path` ,
`UserTestPlan.allow_client_reconnection` and `SyntaxMapCapture.depth`.
Release Notes:
- N/A
Follow-up of
https://github.com/zed-industries/zed/pull/12095#issuecomment-2123230762
reverting back part of https://github.com/zed-industries/zed/pull/11558
that was related to `language.toml` parsing.
Now all extensions that define `prettier_parser_name` in their language
configs, will enable formatting untitled buffers without any extra
language settings like
```json
{
"languages": {
"JSON": {
"prettier": {
"allowed": true,
"parser": "json"
}
}
}
}
```
Release Notes:
- Improved ergonomics of untitled buffer formatting with prettier, no
extra language settings are needed by default.
In #12003 we found ourselves in need for precise region tracking in
which a given runnable has an effect in order to grab variables from it.
This PR makes it so that in task modal all task variables from queries
overlapping current cursor position.
However, in the process of working on that I've found that we cannot
always use a top-level capture to represent the full match range of
runnable (which has been my assumption up to this point). Tree-sitter
captures cannot capture sibling groups; we did just that in Rust
queries.
Thankfully, none of the extensions are affected as in them, a capture is
always attached to single node. This PR adds annotations to them
nonetheless; we'll be able to get rid of top-level captures in extension
runnables.scm once this PR is in stable version of Zed.
Release Notes:
- N/A
Highlight files ending in `mdwn` as Markdown.
(Ikiwiki uses `mdwn` as the file extension for Markdown.)
This pull request was inspired by this one:
- #1209/
Release Notes:
- Added ".mdwn" as a Markdown file extension.
This PR changes the interface of ContextProvider, allowing it to inspect
*all* variables set so far during the process of building
`TaskVariables`. This makes it possible to capture e.g. an identifier in
tree-sitter query, process it and then export it as a task variable.
Notably, the list of variables includes captures prefixed with leading
underscore; they are removed after all calls to `build_context`, but it
makes it possible to capture something and then conditionally preserve
it (and perhaps modify it).
Release Notes:
- N/A
Add config for tag autoclosing: add following to lsp section of your
settings:
"vscode-html-language-server": {
"settings": {
"html": { "tagAutoclosing": true }
}
}
It also accepts `css`, `js/ts` and `javascript` as options.
Disable HTML language server in JS/TS/TSX files for now. I decided to
disable it for now as it caused excessive edits in these types of files
(as reported by @mariansimecek in
https://github.com/zed-industries/zed/pull/11761#issuecomment-2122038107);
it looks like HTML language server tries to track language ranges (e.g.
whether a particular span is TS/HTML fragment etc) just like we do.
However in plain JS/TSX files it seems like it treats the whole file as
one big chunk of HTML, which is.. not right, to say the least.
No release note, as HTML extension goodies are not on Preview yet.
Release Notes:
- N/A
Fixes#5267
TODO:
- [x] Publish our fork of vscode-langservers-extracted on GH and wire
that through as a language server of choice for HTML extension.
- [x] Figure out how to prevent edits made by remote participants from
moving the cursor of a host.
Release Notes:
- Added support for autoclosing of HTML tags in local projects.
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" ]}}}}`
Without this, we'd get constant errors when typing something with ESLint
enabled:
[2024-05-16T10:32:30+02:00 WARN project] Generic lsp request to node
failed: Request textDocument/codeAction failed with message: Cannot read
properties of undefined (reading 'disableRuleComment')
[2024-05-16T10:32:30+02:00 ERROR util]
crates/project/src/project.rs:7023: Request textDocument/codeAction
failed with message: Cannot read properties of undefined (reading
'disableRuleComment')
[2024-05-16T10:32:31+02:00 WARN project] Generic lsp request to node
failed: Request textDocument/codeAction failed with message: Cannot read
properties of undefined (reading 'disableRuleComment')
[2024-05-16T10:32:31+02:00 ERROR util]
crates/project/src/project.rs:7023: Request textDocument/codeAction
failed with message: Cannot read properties of undefined (reading
'disableRuleComment')
This is fixed by changing the default settings for ESLint language
server to have those fields.
I don't think we need to make these configurable yet. These are defaults
that multiple other plugins also use:
- vscode-eslint:
https://sourcegraph.com/github.com/microsoft/vscode-eslint@4d9fc40e71c403d359beaccdd4a6f8d027031513/-/blob/client/src/client.ts?L702-703
- nvim-lspconfig:
https://sourcegraph.com/github.com/neovim/nvim-lspconfig@a27179f56c6f98a4cdcc79ee2971b514815a4940/-/blob/lua/lspconfig/server_configurations/eslint.lua?L94-101
- coc-eslitn:
https://sourcegraph.com/github.com/neoclide/coc-eslint@70eb10d294e068757743f9b580c724e92c5b977d/-/blob/src/index.ts?L698:17-698:35
Release Notes:
- Changed the default ESLint configuration to include the following in
order to silence warnings/errors: `{"codeAction": {
"disableRuleComment": { "enable": true, "location": "separateLine", },
"showDocumentation": { "enable": true } }}`
Closes https://github.com/zed-industries/zed/issues/11517
* Removes forced prettier parser name for languages, making `auto`
command to run prettier on every file by default.
* Moves prettier configs away from plugin language declarations into
language settings
Release Notes:
- N/A
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
We were marking `#[cfg(test)]`ed function as a test, which is wrong.
Also allow for other attribute_items (such as #[should_panic]) between
test attribute and a function item.
Release Notes:
- N/A
Release Notes:
- Improved tasks modal by highlighting a distinction between a task
template and concrete task instance and surfacing available keybindings
more prominently. Task templates are now always available in the modal,
even if there's already a history entry with the same label.
- Changed default key binding for "picker::UseSelectedQuery" to `opt-e`.
RustEmbed repeatedly compiled regexes for handling of
'include='/'exclude' statements in a hot loop, which caused each call to
Assets::iter() to take 600ms. Since it is being called twice on our
startup path, that alone contributed over a second to startup time in
debug builds. I've filed a PR with them
https://github.com/pyrossh/rust-embed/pull/244 which brings down the
time for a single iter() call to 6ms.
Release Notes:
- N/A
This PR moves the Ruby injections added in #8796 to the right location,
since Ruby support was extracted into an extension in #11360.
Release Notes:
- N/A
This PR extracts Ruby and ERB support into an extension and removes the
built-in Ruby and Ruby support from Zed.
As part of this, the new extension is prepared for adding support for
the `Ruby LSP` which has some blockers. See
https://github.com/zed-industries/zed/pull/8613 I was thinking of adding
an initial support for Ruby LSP but I think it would be better to start
with extracting the Ruby extension for now.
The implementation, as the 1st step, matches the bundled version but
with 3 differences:
1. Added signature output to the completion popup. See my comment below.
3. Use the shell environment for starting the `solargraph` executable.
See my comment below.
4. Bumped the tree sitter version for Ruby to the latest available
version.
Additionally, I plan to tweak this extension a bit in the future but I
think we should do this bit by bit. Thanks!
Release Notes:
- Removed built-in support for Ruby, in favor of making it available as
an extension.
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
From now on, only top-level captures are treated as runnable tags and
the rest is appended to task context as custom environmental variables
(unless the name is prefixed with _, in which case the capture is
ignored). This is most likely gonna help with Pest-like test runners.
Release Notes:
- N/A
---------
Co-authored-by: Remco <djsmits12@gmail.com>
Originally reported by @mrnugget and @bennetbo
Also, instead of requerying them every frame, we do so whenever buffer
changes.
As a bonus, I modified tree-sitter query for Rust tests.
Release Notes:
- N/A
Hey guys! `emmet-language-server` author here. Thank you so much for the
amazing editor!
This PR adds more languages to the list for the `emmet-language-server`
to attach to.
I have a question though, I saw that you guys don't differentiate yet
between `JavaScript` and `JSX` files. I know that the tree-sitter parser
for `js` comes with the ability to parse both but we still need to make
that difference. Is that part of the plan? or do you have a reason for
doing that?
Aside from that, I've still added support for `JavaScript` files since
is important to have emmet completions in `JSX` files, but I would like
to know what are your thoughts on that since doing this may pollute the
completions in `.js` files.
And one last thing, the emmet language server accepts more filetypes
such as `pug`, `sass`, `scss` and `less` files, which are not currently
supported by zed. Should I create some extensions to add grammar support
to those files later? Should those extensions be part of the zed repo?
I'm just thinking that those are sort of core languages.
Aside from that, let me know if there's anything left to do on my side.
Greetings!
Fixes#10654.
Release Notes:
- N/A
This allows function call (i.e. snippet) completion with
`typescript-language-server`. So far that didn't work, because
`typescript-language-server` doesn't respond with `insertText` when
getting the completions, but only when then sending
`completionItem/resolve` requests. See:
https://github.com/hrsh7th/nvim-cmp/issues/646#issuecomment-992765479
What this PR does is to support text edits in the response to
`completionItem/resolve`, which means updating the completion item.
It then enables this feature by default for
`typescript-language-server`.
TODOs:
- [x] Make this work over collab
- [x] Test that this doesn't break existing language server support
- [x] Refactor duplicated code
Release Notes:
- Added support for function call completion when using
`typescript-language-server`. This will result in parameters being
added, which can then be changed and navigated with `<tab>`. For this to
work with `typescript-language-server`, the documentation for a given
completion item needs to be resolved, meaning that if one types very
quickly and accepts completion before `typescript-language-server` could
respond with the documentation, no full function completion is used.
Demo:
https://github.com/zed-industries/zed/assets/1185253/c23ebe12-5902-4b50-888c-d9b8cd32965d
This PR adds the ability for the ESLint language server (`eslint`) to be
controlled by the `language_servers` setting.
Now in your settings you can indicate that the ESLint language server
should be used for a given language, even if that language does not have
the ESLint language server registered for it already:
```json
{
"languages": {
"My Language": {
"language_servers": ["eslint", "..."]
}
}
}
```
Release Notes:
- N/A
https://github.com/zed-industries/zed/assets/2072378/18f0bb28-0546-4234-a11f-39af6c9fcc12
`rulesCustomizations` is an array of rule severity overrides. Globs can
be used to apply default severities for multiple rules. See
[docs](553e632fb4/README.md (L312-L333))
& [type
definitions](553e632fb4/%24shared/settings.ts (L168))
Example Zed `settings.json` to override all eslint errors to warnings:
```jsonc
{
"lsp": {
"eslint": {
"settings": {
"rulesCustomizations": [
// set all eslint errors/warnings to show as warnings
{ "rule": "*", "severity": "warn" }
]
}
}
}
}
```
Release Notes:
- Added support for configuring ESLint's `rulesCustomizations` settings,
ie. `{"lsp": {"eslint": {"settings": {"rulesCustomizations": [{"rule":
"*", "severity": "warn"}]}}}}`
This PR adds the ability for the Tailwind language server
(`tailwindcss-language-server`) to be controlled by the
`language_servers` setting.
Now in your settings you can indicate that the Tailwind language server
should be used for a given language, even if that language does not have
the Tailwind language server registered for it already:
```json
{
"languages": {
"My Language": {
"language_servers": ["tailwindcss-language-server", "..."]
}
}
}
```
Release Notes:
- N/A
Adds additional captures for theming rust code.
I'm uncertain about whether `#` belongs in the `@operator` capture, but
I didn't see a more appropriate capture name in my brief hunt in other
files. It is the prefix of an `attribute_item`.. suggestions welcome.
Release Notes:
- Added `@operator`, `@lifetime` and `@punctuation.delimiter` captures
to Rust highlights file.
This PR extracts Elixir support into an extension and removes the
built-in Elixir support from Zed.
As part of this, [Lexical](https://github.com/lexical-lsp/lexical) has
been added as an available language server for Elixir.
Since the Elixir extension provides three different language servers,
you'll need to use the `language_servers` setting to select the one you
want to use:
#### Elixir LS
```json
{
"languages": {
"Elixir": {
"language_servers": [ "elixir-ls", "!next-ls", "!lexical", "..."]
}
}
}
```
#### Next LS
```json
{
"languages": {
"Elixir": {
"language_servers": [ "next-ls", "!elixir-ls", "!lexical", "..."]
}
}
}
```
#### Lexical
```json
{
"languages": {
"Elixir": {
"language_servers": [ "lexical", "!elixir-ls", "!next-ls", "..."]
}
}
}
```
These can either go in your user settings or your project settings.
Release Notes:
- Removed built-in support for Elixir, in favor of making it available
as an extension.
[PKGBUILD] is a file used in the build system of arch linux, and it is
basically just a bash script with special functions.
Release Notes:
- Changed `PKGBUILD` files to be recognized as bash.
This fixes#9934 and does two things:
1. It registers ESLint as a secondary language server for Vue.js files
(`.vue`)
2. It registers ESLint as a _secondary_ (instead of primary) language
server for TypeScript, JavaScript and TSX.
The second point because I don't see any reason why ESLint should be
registered as a primary language server for these languages. I read
through the code in `project.rs` that uses the primary language server
and I don't think there will be any differences to how it previously
worked.
I also manually tested ESLint support in a Vue.js project, a Next.js
project and a plain old JS project — still works in all three.
Release Notes:
- Added ESLint support for Vue.js files by starting it as a language
server on `.vue` files.
([#9934](https://github.com/zed-industries/zed/issues/9934)).
This PR extracts Deno support into an extension and removes the built-in
Deno support from Zed.
When using the Deno extension, you'll want to add the following to your
settings to disable the built-in TypeScript and ESLint language servers
so that they don't conflict with Deno's functionality:
```json
{
"languages": {
"TypeScript": {
"language_servers": ["deno", "!typescript-language-server", "!eslint", "..."]
},
"TSX": {
"language_servers": ["deno", "!typescript-language-server", "!eslint", "..."]
}
}
}
```
Release Notes:
- Removed built-in support for Deno, in favor of making it available as
an extension.
I saved the `file_types.json` file and got a diff because it had some
trailing whitespace. I ran
[`lineman`](https://github.com/JosephTLyons/lineman) on the codebase.
I've done this before, but this time, I've added in the following
settings to our `.zed` local settings, to make sure every future save
respects our desire to have consistent whitespace formatting.
```json
"remove_trailing_whitespace_on_save": true,
"ensure_final_newline_on_save": true
```
Release Notes:
- N/A
Question: I use type.super here because I made a similar change to the
ruby syntax to apply the same style to superclasses.
With this in mind, should this change be renamed to type.trait or should
it be renamed to something like type.italic so the ruby syntax or any
other language can all use type.italic? or maybe something else
altogether.
<img width="597" alt="image"
src="https://github.com/zed-industries/zed/assets/7274458/9d02dba0-75a4-4439-9f31-fd8aa0873075">
Release Notes:
- Exposed Rust traits as `type.interface` for individual syntax theming.
This fixes#9811 by checking for the `solargraph` binary in the `$PATH`
as it's setup in the project shell.
It also adds support for configuring the path to `solargraph` manually:
```json
{
"lsp": {
"solargraph": {
"binary": {
"path": "/Users/thorstenball/bin/solargraph",
"arguments": ["stdio"]
}
}
}
}
```
## Example
Given the following setup:
- `ruby@3.3.0` used globally, no `solargraph` installed globally
- `ruby@3.2.2` used in a project, `solargraph` installed as binstub in
`$project/bin/solargraph`, `.envrc` to configure `direnv` to add
`$project/bin` to `$PATH
Which looks like this in practice:
```shell
# GLOBAL
~ $ ruby --version
ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23]
~ $ which solargraph
solargraph not found
# IN PROJECT
~ $ cd work/projs/rails-proj
direnv: loading ~/work/projs/rails-proj/.envrc
direnv: export ~PATH
~/work/projs/rails-proj $ ruby --version
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin23]
~/work/projs/rails-proj $ which solargraph
/Users/thorstenball/work/projs/rails-proj/bin/solargraph
```
The expectation is that Zed, when opening `~/work/projs/rails-proj`,
picks up the local `solargraph`.
But with **Zed Stable** that doesn't work, as we can see in the logs:
```
2024-04-22T10:21:37+02:00 [INFO] starting language server. binary path: "solargraph", working directory: "/Users/thorstenball/work/projs/rails-proj", args: ["stdio"]
2024-04-22T10:21:37+02:00 [ERROR] failed to start language server "solargraph": No such file or directory (os error 2)
```
With the change in this PR, it uses `rails/proj/bin/solargraph`:
```
[2024-04-22T10:33:06+02:00 INFO language] found user-installed language server for Ruby. path: "/Users/thorstenball/work/projs/rails-proj/bin/solargraph", arguments: ["stdio"]
[2024-04-22T10:33:06+02:00 INFO lsp] starting language server. binary path: "/Users/thorstenball/work/projs/rails-proj/bin/solargraph", working directory: "/Users/thorstenball/work/projs/rails-proj", args: ["stdio"]
```
**NOTE**: depending on whether `mise` (or `rbenv`, `asdf`, `chruby`,
...) or `direnv` come first in the shell-rc file, it picks one or the
other, depending on what puts itself first in `$PATH`.
## Release Notes
Release Notes:
- Added support for finding the Ruby language server `solargraph` in the
user's `$PATH` as it is when `cd`ing into a project's directory.
([#9811](https://github.com/zed-industries/zed/issues/9811))
- Added support for configuring the `path` and `arguments` for
`solargraph` language server manually. Example from settings: `{"lsp":
{"solargraph": {"binary":
{"path":"/Users/thorstenball/bin/solargraph","arguments": ["stdio"]}}}}`
([#9811](https://github.com/zed-industries/zed/issues/9811))
This uses the language server settings added in #9293 to allow users to
specify the binary path and arguments with which to start up `clangd`.
Example user settings for `clangd`:
```json
{
"lsp": {
"clangd": {
"binary": {
"path": "/usr/bin/clangd",
"arguments": ["--log=verbose"]
},
}
}
}
```
Constraints:
* Right now this only allows ABSOLUTE paths.
Release Notes:
- Added ability to specify `clangd` binary `path` (must be absolute) and
`arguments` in user settings. Example: `{"lsp": {"clangd": {"binary":
{"path": "/usr/bin/clangd", "arguments": ["--log=verbose"] }}}}`
Part of https://github.com/zed-industries/zed/issues/5141
* adds "run selection" and "run file" tasks for bash and Python.
* replaces newlines with `\n` symbols in the human-readable task labels
* properly escapes task command arguments when spawning the task in
terminal
Caveats:
* bash tasks will always use user's default shell to spawn the
selections, but they should rather respect the shebang line even if it's
not selected
* Python tasks will always use `python3` to spawn its tasks now, as
there's no proper mechanism in Zed to deal with different Python
executables
Release Notes:
- Added tasks for bash and Python to execute selections and open files
in terminal
Before, `tasks_ui` set most of the context with `SymbolContextProvider`
providing the symbol data part of the context. Now, there's a
`BasicContextProvider` that forms all standard Zed context and it
automatically serves as a base, with no need for other providers like
`RustContextProvider` to call it as before.
Also, stop adding `SelectedText` task variable into the context for
blank text selection.
Release Notes:
- N/A
This PR extracts Vue support into an extension and removes the built-in
C# support from Zed.
Release Notes:
- Removed built-in support for Vue, in favor of making it available as
an extension. The Vue extension will be suggested for download when you
open a `.vue` file.
---------
Co-authored-by: Max <max@zed.dev>
This PR extracts Terraform support into an extension and removes the
built-in Terraform support from Zed.
Release Notes:
- Removed built-in support for Terraform, in favor of making it
available as
an extension. The Terraform extension will be suggested for download
when you
open a `.tf`, `.tfvars`, or `.hcl` file.
Release Notes:
- Extracted lua language support into an extension, and improved Lua
highlighting and completion label styling.
---------
Co-authored-by: Marshall <marshall@zed.dev>
Release Notes:
- Extracted GLSL language support into an extension.
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
New list (used tasks are above the separator line, sorted by the usage
recency), then all language tasks, then project-local and global tasks
are listed.
Note that there are two test tasks (for `test_name_1` and `test_name_2`
functions) that are created from the same task template:
<img width="563" alt="Screenshot 2024-04-10 at 01 00 46"
src="https://github.com/zed-industries/zed/assets/2690773/7455a82f-2af2-47bf-99bd-d9c5a36e64ab">
Tasks are deduplicated by labels, with the used tasks left in case of
the conflict with the new tasks from the template:
<img width="555" alt="Screenshot 2024-04-10 at 01 01 06"
src="https://github.com/zed-industries/zed/assets/2690773/8f5a249e-abec-46ef-a991-08c6d0348648">
Regular recent tasks can be now removed too:
<img width="565" alt="Screenshot 2024-04-10 at 01 00 55"
src="https://github.com/zed-industries/zed/assets/2690773/0976b8fe-b5d7-4d2a-953d-1d8b1f216192">
When the caret is in the place where no function symbol could be
retrieved, no cargo tests for function are listed in tasks:
<img width="556" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/df30feba-fe27-4645-8be9-02afc70f02da">
Part of https://github.com/zed-industries/zed/issues/10132
Reworks the task code to simplify it and enable proper task labels.
* removes `trait Task`, renames `Definition` into `TaskTemplate` and use
that instead of `Arc<dyn Task>` everywhere
* implement more generic `TaskId` generation that depends on the
`TaskContext` and `TaskTemplate`
* remove `TaskId` out of the template and only create it after
"resolving" the template into the `ResolvedTask`: this way, task
templates, task state (`TaskContext`) and task "result" (resolved state)
are clearly separated and are not mixed
* implement the logic for filtering out non-related language tasks and
tasks that have non-resolved Zed task variables
* rework Zed template-vs-resolved-task display in modal: now all reruns
and recently used tasks are resolved tasks with "fixed" context (unless
configured otherwise in the task json) that are always shown, and Zed
can add on top tasks with different context that are derived from the
same template as the used, resolved tasks
* sort the tasks list better, showing more specific and least recently
used tasks higher
* shows a separator between used and unused tasks, allow removing the
used tasks same as the oneshot ones
* remote the Oneshot task source as redundant: all oneshot tasks are now
stored in the inventory's history
* when reusing the tasks as query in the modal, paste the expanded task
label now, show trimmed resolved label in the modal
* adjusts Rust and Elixir task labels to be more descriptive and closer
to bash scripts
Release Notes:
- Improved task modal ordering, run and deletion capabilities
This PR renames `language::Buffer::new` to `language::Buffer::local` and
simplifies its interface. Instead of taking a replica id (which should
always be 0 for the local case) and a `BufferId`, which was awkward and
verbose to construct, it simply takes text and a `cx`.
It uses the `cx` to derive a `BufferId` from the `EntityId` associated
with the `cx`, which should always be positive based on the following
analysis...
We convert the entity id to a u64 using this method on `EntityId`, which
is defined by macros in the `slotmap` crate:
```rust
pub fn as_ffi(self) -> u64 {
(u64::from(self.version.get()) << 32) | u64::from(self.idx)
}
```
If you look at the type of `version` in `KeyData`, it is non-zero:
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct KeyData {
idx: u32,
version: NonZeroU32,
}
```
This commit also adds `Context::reserve_model` and
`Context::insert_model` to determine a model's entity ID before it is
created, which we need in order to assign a `BufferId` in the background
when loading a buffer asynchronously.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
This fixed an issue introduced in
https://github.com/zed-industries/zed/pull/10126, where, when toggling
comments in a language with multiple line comment prefixes (e.g. Gleam,
Erlang) Zed would insert the *last* prefix instead of the first.
Release Notes:
- Fixed an issue where the `toggle comments` command inserted the wrong
line comment prefix in some languages (preview only).
Co-authored-by: Marshall <marshall@zed.dev>
Part of https://github.com/zed-industries/zed/issues/10132 extracted out
of a bigger PR that refactors tasks and shows labels that look more like
commands (ergo needs better readable package names)
Release Notes:
- N/A
This PR adds the ability for extensions to provide certain language
settings via the language `config.toml`.
These settings are then merged in with the rest of the settings when the
language is loaded from the extension.
The language settings that are available are:
- `tab_size`
- `hard_tabs`
- `soft_wrap`
Additionally, for bundled languages we moved these settings out of the
`settings/default.json` and into their respective `config.toml`s .
For languages currently provided by extensions, we are leaving the
values in the `settings/default.json` temporarily until all released
versions of Zed are able to load these settings from the extension.
---
Along the way we ended up refactoring the `Settings::load` method
slightly, introducing a new `SettingsSources` struct to better convey
where the settings are being loaded from.
This makes it easier to load settings from specific locations/sets of
locations in an explicit way.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
