This PR adds a `/now` command to the Assistant for indicating the
current date and time to the model.
Release Notes:
- Added `/now` command to the Assistant for getting the current date and
time.
Hi, this pull request superseeds the
https://github.com/zed-industries/zed/pull/12624
and removes queries for runnables from `outline.scm`. This pull request
has couple things to mention:
- Removed task for running tests with `minitest` as I think it's not
reliable in its state because, AFAIK, the only way to run `minitest`
with the specific line, i.e. `bundle exec rake test
spec/models/some_model.rb:12` is to use it with Rails. The support for
`minitest` is still there and users can add their own task, for
instance, when they use `minitest` in Rails to get support for running
tests:
```json
{
"label": "test $ZED_RELATIVE_FILE:$ZED_ROW",
"command": "./bin/rails",
"args": ["test", "\"$ZED_RELATIVE_FILE:$ZED_ROW\""],
"tags": ["minitest-test"]
}
```
**Question:** Perhaps that should be mentioned in the Ruby extension
documentation?
- Adjusted runnables queries to work without `ZED_SYMBOL`.
Release Notes:
- N/A
This helps with the problem of keyboard input feeling laggy when the
event loop is under load.
What would previously happen is:
- N events from X11 arrive
- N events get forwarded to XIM
- N events are handled in N iterations of the event loop (sadly, yes: we
only seem to be getting back one `ClientMessage` per poll from XCB
connection)
- Each event is pushed into the channel
- N event loop iterations are needed to get the events off the channel
and handle them
With this change, we get rid of the last 2 steps: instead of pushing the
event onto a channel, we store it on the XIM handler itself, and then
work it off synchronously.
Usually one shouldn't block the event loop, but I think in this case -
user input! - it's better to handle the events directly instead of
re-enqueuing them again in a channel, where they can accumulate and need
multiple iterations of the loop to be worked off.
This does *not* fix the problem of input feeling choppy/slower when the
system is under load, but it makes the behavior now feel exactly the
same as when XIM is disabled.
I also think the code is easier to understand since it's more
straightforward.
Release Notes:
- N/A
This change ensures that the event loop prioritizes enqueueing another
render or handling user input over executing runnables.
It's a subtle change as a result of a week of digging into performance
on X11. It's also not perfect: ideally we'd get rid of the intermediate
channel here and had more control over when and how we run runnables vs.
X11 events, but I think short of rewriting how we use an event loop,
this is good cost/benefit change.
To illustrate:
Before this change, it was possible to block the app from rendering for
a long time by just creating a ton of futures that were executed on the
"main" thread (we don't have a "main" thread on Linux, but we have a
single thread in which we run the event loop).
That was relatively easy to reproduce by opening the `zed` repository
and starting `rust-analyzer`: at some point `rust-analyzer` sends us so
many notifications, that are all handled in futures, that the event loop
is busy just working off the runnables, never getting to the events that
X11 sends us or our own timer to re-enqueue another render.
When you put print statements into the code to show when which event was
handled, you'd see something like this **before this change**:
```
[ ... hundreds of runnable.run() ... ]
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 56.942049ms
X11 event
new render tick timer. lag: 9.668µs
X11 event
new render tick timer. lag: 9.955µs
X11 event
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 12.462µs
X11 event
new render tick timer. lag: 14.868µs
X11 event
new render tick timer. lag: 11.234µs
X11 event
new render tick timer. lag: 11.681µs
X11 event
new render tick timer. lag: 13.926µs
X11 event
```
Note the `lag: 56ms`: that's the difference between when we wanted to
execute the callback that enqueues another render and when it ran.
Longer lags are possible, this is just the first one I grabbed from the
logs.
Now, compare this with the logs **after this change**:
```
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 36.051µs
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
X11 event
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
```
In-between many `runnable.run()` we'll always handle events.
So, in essence, what this change does is to introduce 2 priorities into
the X11 event queue:
- high: X11 events (user events, render events, ...), render tick, XIM
events, ...
- low: all async rust code
I've tested this with a debug build and release build and I think the
app now feels more responsive. It doesn't feel perfect still, especially
in the slow debug builds, but I couldn't observe 10s lockups anymore.
Since it's a pretty small change, I think we should go for it and see
how it behaves.
Thanks to @maan2003 this now also includes the same change to Wayland.
Release Notes:
- N/A
---------
Co-authored-by: maan2003 <manmeetmann2003@gmail.com>
This PR is an internal refactor in preparation for remote editing. It
restructures the public interface of `Worktree`, reducing the number of
call sites that assume that a worktree is local or remote.
* The Project no longer calls `worktree.as_local_mut().unwrap()` in code
paths related to basic file operations
* Fewer code paths in the app rely on the worktree's `LocalSnapshot`
* Worktree-related RPC message handling is more fully encapsulated by
the `Worktree` type.
to do:
* [x] file manipulation operations
* [x] sending worktree updates when sharing
for later
* opening buffers
* updating open buffers upon worktree changes
Release Notes:
- N/A
This PR adds a temporary block on publishing v0.0.7 of the
`zed_extension_api`.
We have breaking changes to the extension API that are currently staged
on `main` and are still being iterated on, so we don't want to publish
again until we're ready to commit to the new API.
This change is intended to prevent accidental publishing of the crate
before we're ready.
Release Notes:
- N/A
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 }}}}`.
The `worktree` crate mainly provides an in-memory model of a directory
and its git repositories. But because it was originally extracted from
the Project crate, it also contained lingering bits of code that were
outside of that area:
* it had a little bit of logic related to buffers (though most buffer
management lives in `project`)
* it had a *little* bit of logic for storing diagnostics (though the
vast majority of LSP and diagnostic logic lives in `project`)
* it had a little bit of logic for sending RPC message (though the
*receiving* logic for those RPC messages lived in `project`)
In this PR, I've moved those concerns entirely to the project crate
(where they were already dealt with for the most part), so that the
worktree crate can be more focused on its main job, and have fewer
dependencies.
Worktree no longer depends on `client` or `lsp`. It still depends on
`language`, but only because of `impl language::File for
worktree::File`.
Release Notes:
- N/A
This fixes#12728 as much as I can tell.
The problem was that inside ERB files, when inside Ruby code, we didn't
treat `-` as part of the word, which broke completions.
So, with the change in here, and the following Zed settings, it works.
```json
{
"languages": {
"Ruby": {
"language_servers": ["tailwindcss-language-server", "solargraph"]
}
},
"lsp": {
"tailwindcss-language-server": {
"settings": {
"includeLanguages": {
"erb": "html",
"ruby": "html"
},
"experimental": {
"classRegex": ["\\bclass:\\s*['\"]([^'\"]*)['\"]"]
}
}
}
}
```
This enabled `tailwindcss-language-server` for Ruby files and tells the
language server to look for classes inside `class: ""` strings.
See demo video.
Release Notes:
- Fixed `tailwindcss-language-server` not being activated inside Ruby
strings (inside `.erb`)
([#12728](https://github.com/zed-industries/zed/issues/12728)).
Demo video:
https://github.com/zed-industries/zed/assets/1185253/643343b4-d64f-4c4e-98a1-d10df0b24e31
Co-authored-by: Max Brunsfeld <max@zed.dev>
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
On X11 I was unable to type ä ü and other umlauts in files with
autoclose enabled, because typing ä requires me to hit
- compose key
- `"`
- `a`
When the `"` was typed, Zed would insert a matching `"` because it had a
selection around the dead-key that was inserted by the compose key.
We ran into a similar issue in #7611, but in the case of the Brazilian
keyboard, the `"` is the compose key so we didn't trigger the matching
`"`, because we didn't have a selection yet.
What this does is it fixes the issue by making the
surround-selection-with-quotes-or-brackets also depend on the autoclose
settings, which is didn't do before. This is a breaking change for users
of a Brazilian keyboard layout in which `"` cannot be used to surround
an existing selection with quotes anymore.
That _might_ be a change that users notice, but I can't think of
scenario for that where the user wants, say, `"` to be NOT autoclosed,
but work with selections. (Example is Markdown, for which autoclose for
`"` is disabled. Do we want that but allow surrounding with quotes?)
So it fixes the issue and makes the behavior slightly more consistent,
in my eyes.
Release Notes:
- Changed the behavior of surrounding selections with brackets/quotes to
also depend on the auto-close settings of the language. This is a
breaking change for users of a Brazilian keyboard layout in which `"`
cannot be used to surround an existing selection with quotes anymore.
Before:
[Screencast from 2024-06-04
11-49-51.webm](https://github.com/zed-industries/zed/assets/1185253/6bf255b5-32e9-4ba7-8b46-1e49ace2ba7c)
After:
[Screencast from 2024-06-04
11-52-19.webm](https://github.com/zed-industries/zed/assets/1185253/3cd196fc-20ba-465f-bb54-e257f7f6d9f3)
`base_keymap` is a property of `settings.json`, not `keymap.json`. If
you run "toggle base keymap selector" and select a particular editor,
you will notice that it places the `base_keymap` property in
`settings.json`.
Release Notes:
- N/A
This PR adds the `editor: toggle tab bar` action that hides / shows the
tab bar and updates the `tab_bar.show` setting in `settings.json`
accordingly.
First mentioned in
https://github.com/zed-industries/zed/pull/7356#issuecomment-2118445379.
Release Notes:
- Added the `editor: toggle tab bar` action.
This PR fixes an issue where the prompt library did not properly have
the UI font or rem size set.
Since it is being opened in a new window, we need to re-initialize these
values the same way we do in the main window.
Release Notes:
- N/A
