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
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>
This PR silences the remaining error logs in the `zed` crate tests by
initializing `env_logger` in test mode.
This means that the logs will no longer be shown unless `--nocapture` is
passed to `cargo test`.
Release Notes:
- N/A
This PR registers the Markdown language in some of the tests in the
`zed` crate to silence the error logs about the language not being found
when the chat panel attempts to load it.
Release Notes:
- N/A
This PR fixes a warning I observed when running `cargo doc` against the
`zed` crate:
```
Documenting zed v0.141.0 (/Users/maxdeviant/projects/zed/crates/zed)
warning: this URL is not a hyperlink
--> crates/zed/src/main.rs:860:69
|
860 | /// URLs can either be file:// or zed:// scheme, or relative to https://zed.dev.
| ^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://zed.dev.>`
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
```
Release Notes:
- N/A
This ensures that linux panics still contain symbol names. It also
allows us to profile Zed on linux with `perf` and get symbol names.
Release Notes:
- N/A
This was broken by two things:
1. A merge conflict in the install.sh script leading to bad sh syntax
2. A return removed by accident when we refactored main
Release Notes:
- N/A
> * There are a couple of other `zed` binaries that may be present on
linux systems
([1](https://openzfs.github.io/openzfs-docs/man/v2.2/8/zed.8.html),
[2](https://zed.brimdata.io/docs/commands/zed)). If you want to rename
our CLI
binary because of these issues, we suggest `zedit`, `zeditor`, or
`zed-cli`.
Due to aformentioned issue don't hardcode the executable name in the
.desktop file so envsubst can change it in accordance with the
distributor's requirement.
Resolves#12290.
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>
Fixes#12585
This changes the expectations for installed binaries on linux based on
work
that @jirutka has done for Alpine.
In particular, we now put the cli in place as `bin/zed` and the zed
binary as
`libexec/zed-editor`, and assume that packagers do the same.
cc @someone13574
Release notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
When running the tests for linux, I found a lot of benign errors getting
logged. This PR cuts down some of the noise from unnecessary workspace
serialization and SVG renders
Release Notes:
- N/A
ping #6687
This is the third iteration of this PR ([v2
here](https://github.com/zed-industries/zed/pull/11949)) and uses a
different approach to the first two (the process wrapper lib was a
maintainability nightmare). While the first two attempted to spawn the
necessary processes using flatpak-spawn and host-spawn from the app
inside the sandbox, this version first spawns the cli binary which then
restart's itself *outside* of the sandbox using flatpak-spawn. The
restarted cli process than can call the bundled app binary normally,
with no need for flatpak-spawn because it is already outside of the
sandbox. This is done instead of keeping the cli in the sandbox because
ipc becomes very difficult and broken when trying to do it across the
sandbox.
Gnome software (example using nightly channel and release notes
generated using the script):
<img
src="https://github.com/zed-industries/zed/assets/81528246/6391d217-0f44-4638-9569-88c46e5fc4ba"
width="600"/>
TODO in this PR:
- [x] Bundle libs.
- [x] Cleanup release note converter.
Future work:
- [ ] Auto-update dialog
- [ ] Flatpak auto-update (complete 'Auto-update dialog' first)
- [ ] Experimental
[bundle](https://docs.flatpak.org/en/latest/single-file-bundles.html)
releases for feedback (?).
*(?) = Maybe / Request for feedback*
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Release Notes:
- Improved expand excerpt indicators to allow unidirectional expansion.
Also added the `editor::ExpandExcerptsUp` and
`editor::ExpandExcerptsDown` actions, which can both take a `lines`
parameter. Also added a `expand_excerpt_lines` setting which controls
the default number of lines that the indicators and actions use.
---------
Co-authored-by: conrad <conrad@zed.dev>
Currently the main binary will open an empty file if no previous
workspaces exist or, if it is the first startup, show the welcome page.
When starting via the CLI it will simply drop you in an empty workspace:
no empty file and no welcome page.
This changes the CLI startup to match the behavior of the non-CLI
startup, so they will both create an empty file or show the welcome page
if no path was given and no workspaces were opened in the past.
Release Notes:
- Matched startup behavior of the CLI to the behavior of the main app.
Fixes: #11651
Co-Authored-By: versecafe <147033096+versecafe@users.noreply.github.com>
Release Notes:
- Added a "New Window" item to the dock menu
([#11651](https://github.com/zed-industries/zed/issues/11651)).
---------
Co-authored-by: versecafe <147033096+versecafe@users.noreply.github.com>
This PR removes the wiring for `assistant2` that hooks it up to Zed.
Since we're focusing in on improving the current assistant, we don't
need this present in Zed.
I left the `assistant2` crate intact for now, to make it easier to
reference any code from it.
Release Notes:
- N/A
Data migration plan:
- [X] Make a duplicate table of `copilot_events`
- Name: `inline_completion_events`
- Omit `suggestion_id` column
- [X-reverted-skipping] In collab, continue to match on copilot_events,
but simply stuff their data into inline_completion_events, to forward it
to the new table
- [skipping] Once collab is deployed, ensure no events are being sent to
copilot_events, migrate `copilot_events` to new table via a transaction
- [skipping] Delete `copilot_events` table
---
- [X] Locally test that copilot events sent from old clients get put
into inline_completions_table
- [X] Locally test that copilot events and supermaven events sent from
new clients get put into inline_completions_table
---
- [X] Why are discard events being spammed?
- A:
8d4315712b/crates/editor/src/editor.rs (L2147)
This will throw off the past results for accepted / dismissed that I was
wanting to use to evaluate Supermaven quality, by comparing its rate
with copilot's rate.
I'm not super thrilled with this fix, but I think it'll do. In the
`supermaven_completions_provider`, we check if there's a `completion_id`
before sending either an accepted or discard completion event. I don't
see a similar construct in the `copilot_completions_provider` to
piggyback off of, so I begrudgingly introduced
`should_allow_event_to_send` and had it follow the same pattern that
`completion_id` does. Maybe there's a better way?
---
Adds events to supermaven suggestions. Makes "CopilotEvents" generic ->
"InlineCompletionEvents".
Release Notes:
- N/A
Adding `proxy` keyword to configure proxy while using zed. After setting
the proxy, restart Zed to acctually use the proxy.
Example setting:
```rust
"proxy" = "socks5://localhost:10808"
"proxy" = "http://127.0.0.1:10809"
```
Closes#9424, closes#9422, closes#8650, closes#5032, closes#6701,
closes#11890
Release Notes:
- Added settings to configure proxy in Zed
---------
Co-authored-by: Jason Lee <huacnlee@gmail.com>
This fixes#8794 and other related problems.
The problem, in short, is this: `$SHELL` might be outdated. This code
ensures that we update `$SHELL` to what we can deem the newest version,
if we're started as a desktop application.
The background is that you can get the user's preferred shell in two
ways:
1. Read the `SHELL` env variable
2. Read the `/etc/passwd` file and check which shell is set
Most applications should and do prefer (1) over (2).
Why is it preferred? Reading `SHELL` means that processes can inherit
the variable from each other. And you can do something like
`SHELL=/bin/cool-shell ./my-cool-app`
But what happens if the application was launched from the desktop? Which
SHELL env does it inherit then?
It inherits the env from the process that launched it, which is
Finder.app or launchd or GNOME or something else — these are all
long-running processes that get their environment when the user logs in.
They do *not* get a new environment unless restarted (either process
restarted or computer restarted)
That means the `SHELL` env variable they have might be outdated.
That's a problem if you, for example, change your shell with `chsh` and
then launch the app from the desktop.
That change of the default shell is not reflected in the app if the app
only reads from SHELL. Because that hasn’t been updated. Instead it
should read from passwd file to get the newest value.
Release Notes:
- Fixed SHELL being outdated if Zed was launched via Finder or Raycast
or other desktop launchers.
([#8794](https://github.com/zed-industries/zed/issues/8794))
Part of https://github.com/zed-industries/zed/issues/8081
To avoid confusion and bugs when converting between various row `u32`'s,
use different types for each.
Further PRs should split `Point` into buffer and multi buffer variants
and make the code more readable.
Release Notes:
- N/A
---------
Co-authored-by: Piotr <piotr@zed.dev>
- [x] Build out cli on linux
- [x] Add support for --dev-server-token sent by the CLI
- [x] Package cli into the .tar.gz
- [x] Link the cli to ~/.local/bin in install.sh
Release Notes:
- linux: Add cli support for managing zed
To speed up Linux CI builds, use a set of self-hosted Linux machines and
use them to run all slow CI steps for Linux: "tests", bundling and
nightly builds.
Also adds a set of dev icons as Linux bundling script required them for
`run-bundling`-tagged builds from regular PRs.
Same icons as for Preview were used, but, ideally, something different
could be created.
Release Notes:
- N/A
