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>
Current prettier support w/i Zed leaves out a few languages that are
officially supported by prettier. In particular, Vue and Markdown are
supported by the core prettier project, and PHP is supported via an
official plugin. I didn't see any open issues for this, but I have been
wondering for months why `"formatter": "prettier"` wasn't working on my
PHP files. Now that Zed is open source, I was able to find out why, and
fix it. 😄
I have been using this with PHP files daily for a week+ now, and I have
also used it successfully with Vue and Markdown files, though not as
extensively. I looked around and did not see any tests for specific
prettier language integrations, but if I missed them please let me know
and I'll add some tests.
**Notes**
- I did not add support for Ruby (which has an official prettier plugin)
because it seems to require some external dependencies (notably, Rudy
and some Gems). When those are present on the system and `$PATH`,
prettier will will work just fine on Ruby files if the plugin is set up
similar to how the PHP plugin is set up (I tried it), and I can add that
in here, if desired. The PHP plugin is pure JS (as I recall) and doesn't
have this issue.
- I did *not* add support for languages that have "community" plugins,
though I do note that Zed already ships with prettier support for svelte
enabled, which – if I understand correctly – is powered by a community
plugin. If desired, I could look at adding support/configuration to
enable prettier support for things like elm, erb, glsl, bash, toml.
Bash, in particular, *I* would find useful. 😄
Release Notes:
- Added prettier support for Vue, Markdown and PHP
Hints are still disabled by default in Zed, but when those get enabled,
the language server settings allow to display those instantly without
further server configuration, which might be not obvious. Also add the
documentation enties for those settings and their defaults in Zed.
Closes https://github.com/zed-industries/zed/issues/7821
Release Notes:
- Added default settings for TypeScript and Go LSP servers to enable
inlay hints when those are turned on in Zed
([7821](https://github.com/zed-industries/zed/issues/7821))
In Ruby `_$=@!:?` can all be part of an identifier. If we don't have
them in this list, autocomplete doesn't work as expected.
See: https://gist.github.com/misfo/1072693
This fixes one part of #7819 but not the whole ticket.
Release Notes:
- Fixed completions in Ruby not working for identifiers that start or
end with special characters (e.g.: `@`)
This fixes#7523 by enabling completions with placeholders by default.
This setting controls whether gopls sends back snippets with
placeholders. According to the documentation
(https://github.com/golang/tools/blob/master/gopls/doc/settings.md#useplaceholders-bool)
this only controls whether "placeholders for function parameters or
struct fields" are sent in completion responses.
In practice, though, this seems to also control whether any snippets
with *any* placeholders are being sent back.
Example: for the given Go code
err := myFunction()
i^
With the cursor being at `^`, this setting controls whether `gopls`
sends back statement snippets such as `if err != nil { return ... }`
with the `...` being dynamically matched to the return value of the
function.
So I think this setting controls far more than just function params and
struct fields. And since we *do* support placeholders in snippets, I
think this provides a better default experience.
Release Notes:
- Improved default Go experience by enabling snippets-with-placeholders
when initializing `gopls`.
([#7523](https://github.com/zed-industries/zed/issues/7523)).
At some point go.mod and go.work syntax highlighting quit working. Looks
like the grammars weren't matching for some reason and I'm not sure how
they were working originally.
Not sure if we could write a test to make sure the tree-sitter queries
are being loaded for the grammars or not but seems like something that
could be useful to avoid something like this in the future.
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>
This PR extends our Tree-sitter highlights for Python to allow
highlighting docstrings differently from other strings.
Docstrings in Python will now use `string.doc` instead of just `string`,
which will allow for them to be styled independently of other strings.
If no `string.doc` is present in the theme, then it will fall back to
using the `string` styles.
<img width="272" alt="Screenshot 2024-02-08 at 1 52 21 PM"
src="https://github.com/zed-industries/zed/assets/1486634/034cffa0-91c0-4924-8ccc-3a385cf31126">
This is slightly different than the approach I took in #7585 in that we
are still treating docstrings as strings by default (which appears to be
the more common behavior), but allowing theme authors to hook in and
style them separately, if desired.
Release Notes:
- Added ability add custom styles for Python docstrings using
`string.doc`
([#7346](https://github.com/zed-industries/zed/issues/7346)).
With https://github.com/zed-industries/zed/pull/6882 basic syntax
highlighting support for Terraform has arrived in Zed. To fully support
all features of the language server (when it lands), it's necessary to
handle `*.tfvars` slightly differently.
TL;DR: [terraform-ls](https://github.com/hashicorp/terraform-ls) expects
`terraform` as language id for `*.tf` files and `terraform-vars` as
language id for `*.tfvars` files because the allowed configuration
inside the files is different. Duplicating the Terraform language
configuration was the only way I could see to achieve this.
---
In the
[LSP](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocumentItem),
text documents have a language identifier to identify a document on the
server side to avoid reinterpreting the file extension.
The Terraform language server currently uses two different language
identifiers:
* `terraform` - for `*.tf` files
* `terraform-vars` - for `*.tfvars` files
Both file types contain HCL and can be highlighted using the same
grammar and tree-sitter configuration files. The difference in the file
content is that `*.tfvars` files only allow top-level attributes and no
blocks. [_So you could argue that `*.tfvars` can use a stripped down
version of the grammar_]. To set the right context (which affects
completion, hover, validation...) for each file, we need to send a
different language id.
The only way I could see to achieve this with the current architecture
was to copy the Terraform language configuration with a different `name`
and different `path_suffixes`. Everything else is the same.
A Terraform LSP adapter implementation would then map the language
configurations to their specific language ids:
```rust
fn language_ids(&self) -> HashMap<String, String> {
HashMap::from_iter([
("Terraform".into(), "terraform".into()),
("Terraform Vars".into(), "terraform-vars".into()),
])
}
```
I think it might be helpful in the future to have another way to map
file extensions to specific language ids without having to create a new
language configuration.
### UX Before
### UX After
Release Notes:
- N/A
---
* Part of https://github.com/zed-industries/zed/issues/5098
Fixes https://github.com/zed-industries/zed/issues/7534 by not requiring
assets for gopls and vscode-eslint langservers — those two are the only
ones in Zed that do not use assets directly when determining langserver
version and retrieving those.
All other servers deal with assets, hence require those to be present.
The problem with https://github.com/tamasfe/taplo/releases is that they
host multiple binary releases in the same release list, so for now the
code works because only the langserver has assets — but as soon as
another release there gets assets, it will break again.
We could filter out those by names also, but they also tend to change
(and can be edited manually), so keeping it as is for now.
Release Notes:
- Fixed gopls language server downloads
([7534](https://github.com/zed-industries/zed/issues/7534))
https://github.com/zed-industries/zed/pull/7467 introduced a new
`grammar` field in the language configuration files.
The underlying tree-sitter grammar for Terraform should be `hcl` instead
of `terraform`. This PR fixes that typo.
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>
Terraform and HCL are almost the same language, but not quite so
proposing them as separate languages within Zed. (Terraform is an
extension of HCL, with a different formatter.)
This is just adding the language definition, parsing and highlighting
functionality, not any LSP or formatting beyond that for either
language.
I've taken a bunch of inspiration from Neovim for having the separate
languages, and also lifted some of their `scm` files (with attribution
comments in this codebase) as the tree-sitter repo doesn't contain them.
(Neovim's code is Apache-2.0 licensed, so should be fine here with
attribution from reading Zed's licenses files.) I've then amended to
make sure the capture groups are named for things Zed understands. I'd
love someone from Zed to confirm that's okay, or if I should clean-room
implement the `scm` files.
Highlighting in Terraform & HCL with a moderate amount of syntax in a
file (Terraform on left, HCL on right.)
<img width="1392" alt="Screenshot 2024-01-31 at 18 07 45"
src="https://github.com/zed-industries/zed/assets/696/1d3c9a08-588e-4b8f-ad92-98ce1e419659">
Release Notes:
- (|Improved) ...
([#5098](https://github.com/zed-industries/zed/issues/5098)).
Hi folks! @absynce and I paired a bit to improve the
`elm-language-server` configuration. We have realised that sometimes
`elm-language-server` settings were being reset to default. We had been
configuring `elm-language-server` like this:
```json
"lsp": {
"elm-language-server": {
"initialization_options": {
"disableElmLSDiagnostics": true,
"onlyUpdateDiagnosticsOnSave": true,
"elmReviewDiagnostics": "warning"
}
}
}
```
And then we noticed that the following communication happened:
```
// Send:
{"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{}}}
// Receive:
{"jsonrpc":"2.0","id":5,"method":"workspace/configuration","params":{"items":[{"section":"elmLS"}]}}
// Send:
{"jsonrpc":"2.0","id":5,"result":[null],"error":null}
```
In `elm-language-server` the settings from `didChangeConfiguration`
[replace the initial
settings](https://github.com/elm-tooling/elm-language-server/blob/edd68133883f3902f8940a6e5e2834a9cd627dc1/src/common/providers/diagnostics/diagnosticsProvider.ts#L188).
Setting the value to `{}` effectively resets the configuration options
to defaults.
In Zed, `initialization_options` and `workspace_configuration` are two
different things, but in `elm-language-server` they are coupled.
Additionally, `elm-language-server` is requesting workspace
configuration for the `elmLS` section that doesn't exist.
This PR:
1. Fixes settings reset on `didChangeConfiguration` by populating
`workspace_configuration` from `initialization_options`
2. Makes workspace configuration requests work by inserting an extra
copy of the settings under the `elmLS` key in `workspace_configuration`
— this is a bit ugly, but we're not sure how to make both kinds of
configuration messages work in the current setup.
This is how communication looks like after the proposed changes:
```
// Send:
{
"jsonrpc": "2.0",
"method": "workspace/didChangeConfiguration",
"params": {
"settings": {
"disableElmLSDiagnostics": true,
"onlyUpdateDiagnosticsOnSave": true,
"elmReviewDiagnostics": "warning",
"elmLS": {
"disableElmLSDiagnostics": true,
"onlyUpdateDiagnosticsOnSave": true,
"elmReviewDiagnostics": "warning"
}
}
}
}
// Receive:
{
"jsonrpc": "2.0",
"id": 4,
"method": "workspace/configuration",
"params": {
"items": [
{
"section": "elmLS"
}
]
}
}
// Send:
{
"jsonrpc": "2.0",
"id": 4,
"result": [
{
"disableElmLSDiagnostics": true,
"onlyUpdateDiagnosticsOnSave": true,
"elmReviewDiagnostics": "warning"
}
],
"error": null
}
```
Things we have considered:
1. Extracting the `elm-language-server` settings into a separate
section: we haven't found this being widely used in Zed, seems that all
language server configuration should fall under the top level `lsp`
section
2. Changing the way `elm-language-server` configuration works:
`elm-language-server` has got integrations with multiple editors,
changing the configuration behaviour would mean updating all the
existing integrations. Plus we are not exactly sure if it's doing
anything wrong.
Release Notes:
- Improved elm-language-server configuration options
Co-authored-by: Jared M. Smith <absynce@gmail.com>
This changes the highlighting of Go code to make it more similar to how
we highlight Rust
* normal variables have the normal color, vs. being highlighted. This
really stuck out.
* brackets are properly highlighted
It also brings it closer to Neovim's tree-sitter highlighting by
changing how struct fields are highlighted.
Release Notes:
- Improved highlighting of Go code by tuning highlighting of variables,
brackets, and struct fields.
## Before & After
Release Notes:
- Added bash syntax highlighting to `.env` files.
- Added a `private_files` setting for configuring which files should be
considered to contain environment variables or other sensitive
information.
- Added a `redact_private_values` setting to add or remove censor bars
over variable values in files matching the `private_files` patterns.
-(internal) added a new `redactions.scm` query to our language support,
allowing different config file formats to indicate where environment
variable values can be identified in the syntax tree, added this query
to `bash`, `json`, `toml`, and `yaml` files.
---------
Co-authored-by: Nathan <nathan@zed.dev>
On a .zig files , the `CMD-/` keybinding don't work,
In the language config its the only language with '//' type comment that
is written in singular without array.
This fixed the problem, so i assume it was just a typo
Release notes:
- Fixed line comment continuations and Editor::ToggleComments for Zig, Haskell and PureScript.
Marshall Bowers
claytonrcarter
Robin Pfäffle
Thorsten Ball
Derrick Laird
Alvaro GaonaandNate Butler
Paulo Roberto de Oliveira CastroandPiotr Osiewicz
Matthew Gramigna
Jason LeeandMarshall Bowers
Daniel Banck
Mikayla Maki
Max BrunsfeldandMarshall
Bennet Bo FennerandRemco Smits
Pseudomata
Caius Durling
Conrad Irwin
Andrey KuzminandJared M. Smith
Rashid Almheiri
Dairon MandThanabodee Charoenpiriyakij
fminkowski
Ammar Arif
Ben Hamment
bestgopher
Abel Chalier
Iván Molina Rebolledo
Stuart Hinson
