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
Now, regardless of how the Zed window is closed, Zed can remember the
window's restore size.
- [x] Windows implementation
- [x] macOS implementation
- [x] Linux implementation (partial)
- [x] update SQL data base (mark column `fullscreen` as deprecated)
The current implementation on Linux is basic, and I'm not sure if it's
correct.
The variable `fullscreen` in SQL can be removed, but I'm unsure how to
do it.
edit: mark `fullscreen` as deprecated
### Case 1
When the window is closed as maximized, reopening it will open in the
maximized state, and returning from maximized state will restore the
position and size it had when it was maximized.
https://github.com/zed-industries/zed/assets/14981363/7207752e-878a-4d43-93a7-41ad1fdb3a06
### Case 2
When the window is closed as fullscreen, reopening it will open in
fullscreen mode, and toggling fullscreen will restore the position and
size it had when it entered fullscreen (note that the fullscreen
application was not recorded in the video, showing a black screen, but
it had actually entered fullscreen mode).
https://github.com/zed-industries/zed/assets/14981363/ea5aa70d-b296-462a-afb3-4c3372883ea3
### What's more
- As English is not my native language, some variable and struct names
may need to be modified to match their actual meaning.
- I am not familiar with the APIs related to macOS and Linux, so
implementation for these two platforms has not been done for now.
- Any suggestions and ideas are welcome.
Release Notes:
- N/A
This PR adds a new development credentials provider for the purpose of
streamlining local development against production collab.
## Problem
Today if you want to run a development build of Zed against the
production collab server, you need to either:
1. Enter your keychain password every time in order to retrieve your
saved credentials
2. Re-authenticate with zed.dev every time
- This can get annoying as you need to pop out into a browser window
- I've also seen cases where if you re-auth too many times in a row
GitHub will make you confirm the authentication, as it looks suspicious
## Solution
This PR decouples the concept of the credentials provider from the
keychain, and adds a new development credentials provider to address
this specific case.
Now when running a development build of Zed and the
`ZED_DEVELOPMENT_AUTH` environment variable is set to a non-empty value,
the credentials will be saved to disk instead of the system keychain.
While this is not as secure as storing them in the system keychain,
since it is only used for development the tradeoff seems acceptable for
the resulting improvement in UX.
Release Notes:
- N/A
This PR adds a registry for `GitHostingProvider`s.
The intent here is to help decouple these provider-specific concerns
from the lower-level `git` crate.
Similar to languages, the Git hosting providers live in the new
`git_hosting_providers` crate.
This work also lays the foundation for if we wanted to allow defining a
`GitHostingProvider` from within an extension. This could be useful if
we wanted to extend the support to work with self-hosted Git providers
(like GitHub Enterprise).
I also took the opportunity to move some of the provider-specific code
out of the `util` crate, since it had leaked into there.
Release Notes:
- N/A
Notable things I've had to fix due to 1.78:
- Better detection of unused items
- New clippy lint (`assigning_clones`) that points out places where assignment operations with clone rhs could be replaced with more performant `clone_into`
Release Notes:
- N/A
Adds a supermaven provider for completions. There are various other
refactors amidst this branch, primarily to make copilot no longer a
dependency of project as well as show LSP Logs for global LSPs like
copilot properly.
This feature is not enabled by default. We're going to seek to refine it
in the coming weeks.
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This undoes the changes from #11333 and uses the path of the `.desktop`
file instead.
According ot the spec
(https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html)
the filename and path of the `desktop` file are used to determine the
desktop file ID.
This is enough to match the windows (which have the same WMClass/app-id)
with the desktop entry.
Release Notes:
- N/A
Since we do want to have different versions of Zed running on the same
Linux install, we need to give them different application IDs so they're
not grouped together as the same application.
This changes the app_id depending on the releaes channel and, crucially,
it also matches them up with the bundle identifiers that we use on
macOS.
Release Notes:
- N/A
Co-Authored-By: Mikayla <mikayla@zed.dev>
In a fit of ill-advisedness I called these things remote projects;
forgetting that remote project is also what we call collaboratively
shared projects.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
Release Notes:
- Added diagnostics for main-thread hangs on macOS. These are only
enabled if you've opted into diagnostics.
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR adds support for replacing the current preview tab when using
GoToDefinition. Previously a tab, that was navigated away from, was
converted into a permanent tab and the new tab was opened as preview.
Without `enable_preview_from_code_navigation`:
https://github.com/zed-industries/zed/assets/53836821/99840724-d6ff-4738-a9c4-ee71a0001634
With `enable_preview_from_code_navigation`:
https://github.com/zed-industries/zed/assets/53836821/8c60efcb-d597-40bf-b08b-13faf5a289b6
Note: In the future I would like to improve support for the navigation
history, because right now tabs that are not "normal" project items,
e.g. FindAllReferences cannot be reopened
Release Notes:
- Added support for replacing the current preview tab when using code
navigation (`enable_preview_from_code_navigation`)
fixes https://github.com/zed-industries/zed/issues/9132
By setting the app id, window managers like `sway` can apply custom
configuration like `for_window [app_id="zed"] floating enable`.
Tested using `wlprop`/`hyprctl activewindow` for wayland, `xprop` for
x11.
Release Notes:
- Zed now sets the window app id / class, which can be used e.g. in
window managers like `sway`/`i3` to define custom rules
Addresses #10812
Release Notes:
- Launching an empty already-running Zed application now behaves like a
regular startup and respects the user `resume_on_startup` setting.
([#10812](https://github.com/zed-industries/zed/issues/10812)).
See attached showcase which highlights how the previous project can now
be re-opened through both "quit" and "close window".
This has a noticeable performance benefit on startup/project resume
time.
This should also make the behaviour of closing/opening an application
consistent between macOS/Linux/Windows.
https://github.com/zed-industries/zed/assets/22855292/9c37ba31-ce0a-4c3d-940d-a56e3347e64a
This is a follow up of #10810 , `embed-resource` crate uses a different
method to link the manifest file, so this makes moving manifest file to
`gpui` possible.
Now, examples can run as expected:
TODO:
- [ ] check if it builds with gnu toolchain
Release Notes:
- N/A
use winresource for crates/zed and crates/storybook. tested on
`x86_64-pc-windows-gnu`. on `x86_64-pc-windows-msvc` I receive a error
message, that looks like a problem with my machine
Release Notes:
- N/A
