We saw this panic come up:
```
called `Result::unwrap()` on an `Err` value: IoError(Custom { kind: Other, error: UnknownError })
core::panicking::panic_fmt
core::result::unwrap_failed
<gpui::platform::linux::x11:🪟:X11Window as core::ops::drop::Drop>::drop
core::ptr::drop_in_place<gpui::platform::linux::x11:🪟:X11Window>
core::ptr::drop_in_place<gpui:🪟:Window>
gpui::app::AppContext::shutdown
gpui::app::AppContext:🆕:{{closure}}
gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run
gpui::app::App::run
zed::main
std::sys_common::backtrace::__rust_begin_short_backtrace
std::rt::lang_start::{{closure}}
std::rt::lang_start_internal
main
__libc_start_call_main
__libc_start_main_impl
_start
```
I'm not sure where exactly that error comes from, except from the X11
stuff. So let's be defensive and log error and only then tear down
everything.
I _think_ that if the error is repeatable that means we won't close the
window but instead just log errors, but I do think that's better than
panicking right now.
Release Notes:
- N/A
### TODO
- [x] Make sure keybinding shows up in pane + menu
- [x] Selection tool in the editor toolbar
- [x] Application Menu
- [x] Add more options to pane + menu
- Go to File...
- Go to Symbol in Project...
- [x] Add go items to the selection tool in the editor:
- Go to Symbol in Editor...
- Go to Line/Column...
- Next Problem
- Previous Problem
- [x] Fix a bug where modals opened from a context menu aren't focused
correclty
- [x] Determine if or what needs to be done with project actions:
- Difficulty is that these are exposed in the UI via clicking the
project name in the titlebar or by right clicking the root entry in the
project panel. But they require reading and are two clicks away. Is that
sufficient?
- Add Folder to Project
- Open a new project
- Open recent
- [x] Get a style pass
- [x] Implement style pass
- [x] Fix the wrong actions in the selection menu
- [x] Show selection tool toggle in the 'editor settings' thing
- [x] Put preferences section from the app menu onto the right hand user
menu
- [x] Add Project menu into app menu to replace 'preferences' section,
and put the rest of the actions there
- [ ] ~~Adopt `...` convention for opening a surface~~ uncertain what
this convention is.
- [x] Adopt link styling for webview actions
- [x] Set lucide hamburger for menu icon
- [x] Gate application menu to only show on Linux and Windows
Release Notes:
- Added a 'selection and movement' tool to the Editor's toolbar, as well
as controls to toggle it and a setting to remove it (`"toolbar":
{"selections_menu": true/false }`)
- Changed the behavior of the `+` menu in the tab bar to use standard
actions and keybindings. Replaced 'New Center Terminal' with 'New
Terminal', and 'New Search', with the usual 'Deploy Search'. Also added
item-creating actions to this menu.
- Added an 'application' menu to the titlebar to Linux and Windows
builds of Zed
Fixes https://github.com/zed-industries/zed/issues/12054
Replaces the `copypasta`/`smithay-clipboard` implementation with a new,
custom one
TODO list:
- [x] Cleanup code
- [x] Remove `smithay-clipboard`
- [x] Add more mime types to the supported list
Release Notes:
- Fixed drag and drop on Gnome
- Fixed clipboard paste on Hyprland
This fixes everything but the main Zed window (GPUI examples, prompt
library, etc.) not being closable by clicking on the X in X11.
We had a dangling reference before: we would remove the window from the
X11 state, but GPUI itself would still have the window in its
references.
In order to fix this we have to call `window.close()`, which ends up
calling `cx.remove_window()`, which removes the reference.
That in turn then causes the reference to be dropped, which cleans up
the X11 state for the window.
Release Notes:
- N/A
Release Notes:
- Added a more detailed message in place of the generic `checking...`
messages when Rust-analyzer is running.
- Added a rate limit for language server status messages, to reduce
noisiness of those updates.
- Added a `cancel language server work` action which will cancel
long-running language server tasks.
---------
Co-authored-by: Richard <richard@zed.dev>
Run any Jupyter kernel in Zed on any buffer (editor):
<img width="1074" alt="image"
src="https://github.com/zed-industries/zed/assets/836375/eac8ed69-d02b-4d46-b379-6186d8f59470">
## TODO
### Lifecycle
* [x] Launch kernels on demand
* [x] Wait for kernel to be started
* [x] Request Kernel info on start
* [x] Show in progress indicator
* [ ] Allow picking kernel (it defaults to first matching language name)
* [ ] Menu for interrupting and shutting down the kernel
* [ ] Drop running kernels once editor is dropped
### Media Outputs
* [x] Render text and tracebacks with ANSI color handling
* [x] Render markdown as text
* [x] Render PNG and JPEG images using an explicit height based on
line-height
* ~~Render SVG~~ -- not happening for this PR due to lack of text in SVG
support
* [ ] Process `update_display_data` message and related `display_id`
* [x] Process `page` data from payloads as outputs
* [ ] Render markdown as, well, rendered markdown -- Note: unsure if we
can get line heights here
### Document
* [x] Select code and run
* [x] Run current line
* [x] Clear previous overlapping runs
* [ ] Support running markdown code blocks
* [ ] Action to export session as notebook or output files
* [ ] Action to clear all outputs
* [ ] Delete outputs when lines are deleted
## Other missing features
The following is a list of missing functionality or expectations that
are out of scope for this PR.
### Python Environments
Detecting python environments should probably be done in a separate PR
in tandem with how they're used with LSP. Users likely want to pick an
environment for their project, whether a virtualenv, conda env, pyenv,
poetry backed virtualenv, or the system. Related issues:
* https://github.com/zed-industries/zed/issues/7646
* https://github.com/zed-industries/zed/issues/7808
* https://github.com/zed-industries/zed/issues/7296
### LSP Integration
* Submit `complete_request` messages for completions to interleave
interactive variables with LSP
* LSP for IPython semantics (`%%timeit`, `!ls`, `get_ipython`, etc.)
## Future release notes
- Run code in any editor, whether it's a script or a markdown document
Release Notes:
- N/A
Release Notes:
- Now when an editor loses focus (e.g. from switching tabs) and then
gains focus again, it doesn't close the inline assist. Instead, it only
closes when you move the cursor outside of it, e.g. by clicking
somewhere else in its parent editor.
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
- Update `windows-rs` from `0.56` to `0.57`
- Use the newly introduced `Owned` struct in `0.57` to handle the RAII
stuff of `HANDLE`
- Better error handling in `DirectWrite`
Release Notes:
- N/A
Note:
- We have disabled all tests that rely on Postgres in the Linux CI. We
only really need to test these once, and as macOS is our team's primary
platform, we'll only enable them on macOS for local reproduction.
- We have disabled all tests that rely on the font metrics. We
standardized on Zed Mono in many fonts, but our CoreText Text System and
Cosmic Text System proved to be very different in effect. We should
revisit if we decide to standardize our text system across platforms
(e.g. using Harfbuzz everywhere)
- Extended the condition timeout significantly. Our CI machines are slow
enough that this is causing spurious errors in random tests.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
On most platforms, things were working correctly, but had the wrong
type. On X11, there were some problems with window and display size
calculations.
Release Notes:
- Fixed issues with window positioning on X11
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR adds support for `org.gnome.desktop.interface`'s `cursor-theme`
setting on Wayland. This should fix cursors not showing up on some GNOME
installs. This PR also adds the wiring to watch the current cursor theme
value.
Thanks to @apricotbucket28 for helping debug the issue.
Release Notes:
- N/A
TODO:
- [x] Finish GPUI changes on other operating systems
This is a largely internal change to how we report data to our
diagnostics and telemetry. This PR also includes an update to our blade
backend which allows us to report errors in a more useful way when
failing to initialize blade.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Turns out we still get FocusOut and UnmapNotify events after the window
has been destroyed, which resulted in error messages popping up because
we can't find the window anymore that we want to mark as unfocused.
Release Notes:
- N/A
I noticed that when I use my mouse wheel, we get a ton of the
`XkbStateNotify` events, but the modifiers don't change, so we add a ton
of useless input events for the window.
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 reverts commit 1a0708f28c since after
that, default task-related keybindings (alt-t and alt-shift-t) started
to leave `†` and `ˇ` symbols in the text editors before triggering
actions.
Release Notes:
- N/A
fixes#11829
In https://github.com/zed-industries/zed/pull/7494, we introduced IME
event buffering, so that we could preempt the IME with a keystroke event
in some cases. However, this caused a desynchronization bug in long
multi-step IME composition, such as the pre-edit used in the Japanese
Romaji keyboard (and other languages). We found that this was due to the
IME issuing actions, and then immediately querying the editor's state
before we had applied those actions. Therefore, this PR removes IME
action buffering.
We have tested all of the cases in the `handle_key_event` documentation
and added a few of our own.
Release Notes:
- Fixed an issue where the IME pre-edit could desynchronize from the
editor on macOS
([#11829](https://github.com/zed-industries/zed/pull/12651))
---------
Co-authored-by: Jan Solanti <jhs@psonet.com>
This could still use some improvement UI-wise but the user experience
should be a lot better.
- [x] Show in "Window" application menu
- [x] Load prompt as it's selected in the picker
- [x] Refocus picker on `esc`
- [x] When creating a new prompt, if a new prompt already exists and is
unedited, activate it instead
- [x] Add `/default` command
- [x] Evaluate /commands on prompt insertion
- [x] Autocomplete /commands (but don't evaluate) during prompt editing
- [x] Show token count using the settings model, right-aligned in the
editor
- [x] Picker
- [x] Sorted alpha
- [x] 2 sublists
- Default
- Empty state: Star a prompt to add it to your default prompt
- Otherwise show prompts with star on hover
- All
- Move prompts with star on hover
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/10890
* removes `unwrap()` that caused panics for text elements with no text,
remaining after edit state is cleared but project entries are not
updated, having the fake, "new entry"
* improves discoverability of the FS errors during file/directory
creation: now those are shown as workspace notifications
* stops printing anyhow backtraces in workspace notifications, printing
the more readable chain of contexts instead
* better indicates when new entries are created as excluded ones
Release Notes:
- Improve excluded entry creation workflow in the project panel
([10890](https://github.com/zed-industries/zed/issues/10890))
`[NSString UTF8String]` sometimes returns null (it's documented as
such), and when it does, zed crashes in `window::insert_text`. I'm
running into this sometimes when using alt-d to delete forward. It
usually only happens with multiple cursors, but sometimes with a single
cursor. It *might* only happen when using the "Unicode Hex Input"
keyboard 'Input Source' (which I started using to avoid entering weird
characters in zed when using emacs meta keybindings that I haven't
defined in zed).
When using the US English input source, alt-d always results in a call
to `insert_text`. When using the Unicode Hex Input source it usually
doesn't, but when it does `text.UTF8String()` returns null. `text` isn't
null. `[text length]` returns 1. `[text characterAtIndex: 0]` seems to
always return `56797` (an undefined utf-16 codepoint).
Release Notes:
- Fixed crash on mac when deleting with alt-d
Fixes multiple issues that prevented window bounds restoration to not
work on Wayland.
Note: Since the display uuid depends on the `wl_output.name` field, this
only works properly on KDE 5.26+ or Gnome 44+ ([kwin
commit](330a02d862),
[mutter](7e838b1115)).
Release Notes:
- N/A
