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)).
This PR adds a view for installing extensions within Zed.
My subtasks:
- [X] Page Extensions and assign in App Menu
- [X] List extensions
- [X] Button to Install/Uninstall
- [x] Search Input to search in extensions registry API
- [x] Get Extensions from API
- [x] Action install to download extension and copy in /extensions
folder
- [x] Action uninstall to remove from /extensions folder
- [x] Filtering
- [x] Better UI Design
Open to collab!
Release Notes:
- Added an extension installation view. Open it using the `zed:
extensions` action in the command palette
([#7096](https://github.com/zed-industries/zed/issues/7096)).
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Carlos <foxkdev@gmail.com>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Max <max@zed.dev>
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>
- Open channel notes and chat on channel click
- WIP
- Fix compile error
- Don't join live kit until requested
- Track in_call state separately from in_room
Release Notes:
- Improved channels: you can now be in a channel without joining the
audio call automatically
**or**
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Before the change to `script/clippy`, bash ignored first `clippy`
invocation failure and CI moved on with Linux errors and warnings
emitted.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
On macOS, this will enable or disable the Metal HUD at runtime. Note
that this only works when Zed is bundled because it requires to set the
`MetalHudEnabled` key in the Info.plist.
Release Notes:
- Added a new `ToggleGraphicsProfiler` command that can be used as an
action (or via the `Help -> Toggle Graphics Profiler` menu) to
investigate graphics performance.
This is a refactor, follow-up to the work we've been doing on loading
WASM language extensions.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
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))
This PR updates the various spots where we reload the theme to use
`ThemeSettings::reload_current_theme` instead of duplicating the code
each time.
Release Notes:
- N/A
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>
This PR changes our approach to initializing the `SystemAppearance` so
that we can do it earlier in the startup process.
Previously we were using the appearance from the window, meaning that we
couldn't initialize the value until we first opened the window.
Now we read the `window_appearance` from the `AppContext`. On macOS this
is backed by the
[`effectiveAppearance`](https://developer.apple.com/documentation/appkit/nsapplication/2967171-effectiveappearance)
on the `NSApplication`.
We currently still watch for changes to the appearance at the window
level, as the only hook I could find in the documentation is
[`viewDidChangeEffectiveAppearance`](https://developer.apple.com/documentation/appkit/nsview/2977088-viewdidchangeeffectiveappearance),
which is at the `NSView` level.
In my testing this makes it so Zed appropriately chooses the correct
light/dark theme on startup.
Release Notes:
- N/A
Reverts zed-industries/zed#7481
This would regress performance because we'd be using the standard
library's hash maps everywhere, so reverting for now.
Turns out that Nushell doesn't like `-lic` and `&&`, but works perfectly
fine with `-l -i -c` and `;`, which the other shells do too.
These all work:
bash -l -i -c 'echo lol; /usr/bin/env -0'
nu -l -i -c 'echo lol; /usr/bin/env -0'
zsh -l -i -c 'echo lol; /usr/bin/env -0'
fish -l -i -c 'echo lol; /usr/bin/env -0'
Release Notes:
- Fixed shell environment not being loaded if Nushell was set as
`$SHELL`.
This PR adds support for configuring both a light and dark theme in
`settings.json`.
In addition to accepting just a theme name, the `theme` field now also
accepts an object in the following form:
```jsonc
{
"theme": {
"mode": "system",
"light": "One Light",
"dark": "One Dark"
}
}
```
Both `light` and `dark` are required, and indicate which theme should be
used when the system is in light mode and dark mode, respectively.
The `mode` field is optional and indicates which theme should be used:
- `"system"` - Use the theme that corresponds to the system's
appearance.
- `"light"` - Use the theme indicated by the `light` field.
- `"dark"` - Use the theme indicated by the `dark` field.
Thank you to @Yesterday17 for taking a first stab at this in #6881!
Release Notes:
- Added support for configuring both a light and dark theme and
switching between them based on system preference.
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)).
Link error:
= note: /nix/store/idiaraknw071d20nlqp49s18gbvw4wa0-binutils-2.40/bin/ld: /x/Code/zed/target/x86_64-unknown-linux-gnu/debug/deps/libtree_sitter_haskell-7323f782ad886c6d.rlib(scanner.o): in function `state_new':
/home/kvark/.cargo/git/checkouts/tree-sitter-haskell-74c278e7a2ef8d7d/cf98de2/src/scanner.c:218: multiple definition of `state_new'; /x/Code/zed/target/x86_64-unknown-linux-gnu/debug/deps/libtree_sitter_purescript-b0a95fb604a5817c.rlib(scanner.o):/home/kvark/.cargo/git/checkouts/tree-sitter-purescript-88dd3ec656c48026/a37140f/src/scanner.c:218: first defined here
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](edd6813388/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>
