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>
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 is still pretty raw, so I'd like to hold off on shipping it to all
users.
Release Notes:
- Hide the prompt library for non-staff until it is in a more complete
state.
* Start with a longer duration
* Widen the range used for randomizing the duration between retries
* Increase the maximum duration between retries
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)
![scr-20240514-pqmg](https://github.com/zed-industries/zed/assets/19867440/e51e7ae4-21b8-47a2-bfaa-f68fb355e409)
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 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
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
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 is a crate only addition of a new version of the AssistantPanel.
We'll be putting this behind a feature flag while we iron out the new
experience.
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
Co-authored-by: Nate Butler <nate@zed.dev>
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Max <max@zed.dev>
Release Notes:
- Made remote projects per-user instead of per-channel. If you'd like to
be part of the remote development alpha, please email hi@zed.dev.
---------
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
Co-authored-by: Bennet <bennetbo@gmx.de>
Co-authored-by: Nate Butler <1714999+iamnbutler@users.noreply.github.com>
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
This PR flips the optionality of the `AutoUpdateSettingContent` to make
it a bit easier to work with.
#### Before
```rs
struct AutoUpdateSettingContent(Option<bool>);
type FileContent = AutoUpdateSettingContent;
```
#### After
```rs
struct AutoUpdateSettingContent(bool);
type FileContent = Option<AutoUpdateSettingContent>;
```
Release Notes:
- N/A
This puts the Linux platform implementation at a similar code style and
quality to the macOS platform. The largest change is that I collapsed
the `LinuxPlatform` -> `[Backend]` -> `[Backend]State` ->
`[Backend]StateInner` to just `[Backend]` and `[Backend]State`, and in
the process removed most of the `Rc`s and `RefCell`s.
TODO:
- [x] Make sure that this is on-par with the existing implementation
- [x] Review in detail, now that the large changes are done.
- [ ] Update the roadmap
Release Notes:
- N/A
This PR adds the ability for extensions to provide certain language
settings via the language `config.toml`.
These settings are then merged in with the rest of the settings when the
language is loaded from the extension.
The language settings that are available are:
- `tab_size`
- `hard_tabs`
- `soft_wrap`
Additionally, for bundled languages we moved these settings out of the
`settings/default.json` and into their respective `config.toml`s .
For languages currently provided by extensions, we are leaving the
values in the `settings/default.json` temporarily until all released
versions of Zed are able to load these settings from the extension.
---
Along the way we ended up refactoring the `Settings::load` method
slightly, introducing a new `SettingsSources` struct to better convey
where the settings are being loaded from.
This makes it easier to load settings from specific locations/sets of
locations in an explicit way.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This pull request introduces a new `InlineCompletionProvider` trait,
which enables making `Editor` copilot-agnostic and lets us push all the
copilot functionality into the `copilot_ui` module. Long-term, I would
like to merge `copilot` and `copilot_ui`, but right now `project`
depends on `copilot`, which makes this impossible.
The reason for adding this new trait is so that we can experiment with
other inline completion providers and swap them at runtime using config
settings.
Please, note also that we renamed some of the existing copilot actions
to be more agnostic (see release notes below). We still kept the old
actions bound for backwards-compatibility, but we should probably remove
them at some later version.
Also, as a drive-by, we added new methods to the `Global` trait that let
you read or mutate a global directly, e.g.:
```rs
MyGlobal::update(cx, |global, cx| {
});
```
Release Notes:
- Renamed the `copilot::Suggest` action to
`editor::ShowInlineCompletion`
- Renamed the `copilot::NextSuggestion` action to
`editor::NextInlineCompletion`
- Renamed the `copilot::PreviousSuggestion` action to
`editor::PreviousInlineCompletion`
- Renamed the `editor::AcceptPartialCopilotSuggestion` action to
`editor::AcceptPartialInlineCompletion`
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Kyle <kylek@zed.dev>
Co-authored-by: Kyle Kelley <rgbkrk@gmail.com>
* Store extensions versions' wasm API version in the database
* Share a common struct for extension API responses between collab and
client
* Add wasm API version and schema version to extension API responses
Release Notes:
- N/A
Co-authored-by: Marshall <marshall@zed.dev>
This PR provides some of the plumbing needed for a "remote" zed
instance.
The way this will work is:
* From zed on your laptop you'll be able to manage a set of dev servers,
each of which is identified by a token.
* You'll run `zed --dev-server-token XXXX` to boot a remotable dev
server.
* From the zed on your laptop you'll be able to open directories and
work on the projects on the remote server (exactly like collaboration
works today).
For now all this PR does is provide the ability for a zed instance to
sign in
using a "dev server token". The next steps will be:
* Adding support to the collaboration protocol to instruct a dev server
to "open" a directory and share it into a channel.
* Adding UI to manage these servers and tokens (manually for now)
Related #5347
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Resurrected this from some assistant work I did in Spring of 2023.
- [x] Resurrect streaming responses
- [x] Use streaming responses to enable AI via Zed's servers by default
(but preserve API key option for now)
- [x] Simplify protobuf
- [x] Proxy to OpenAI on zed.dev
- [x] Proxy to Gemini on zed.dev
- [x] Improve UX for switching between openAI and google models
- We current disallow cycling when setting a custom model, but we need a
better solution to keep OpenAI models available while testing the google
ones
- [x] Show remaining tokens correctly for Google models
- [x] Remove semantic index
- [x] Delete `ai` crate
- [x] Cloud front so we can ban abuse
- [x] Rate-limiting
- [x] Fix panic when using inline assistant
- [x] Double check the upgraded `AssistantSettings` are
backwards-compatible
- [x] Add hosted LLM interaction behind a `language-models` feature
flag.
Release Notes:
- We are temporarily removing the semantic index in order to redesign it
from scratch.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: Max <max@zed.dev>
Also adds a new command `cli: Register Zed Scheme` that will cause URLs
to be opened in the current zed version, and we call this implicitly if
you install the CLI
Also add some status reporting to install cli
Fixes: #8857
Release Notes:
- Added success/error reporting to `cli: Install Cli`
([#8857](https://github.com/zed-industries/zed/issues/8857)).
- Removed `zed-{preview,nightly,dev}:` url schemes (used by channel
links)
- Added `cli: Register Zed Scheme` to control which zed handles the
`zed://` scheme (defaults to the most recently installed, or
the version that you last used `cli: Install Cli` with)
This PR wires up support for [Azure
OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview)
as an alternative AI provider in the assistant panel.
This can be configured using the following in the settings file:
```json
{
"assistant": {
"provider": {
"type": "azure_openai",
"api_url": "https://{your-resource-name}.openai.azure.com",
"deployment_id": "gpt-4",
"api_version": "2023-05-15"
}
},
}
```
You will need to deploy a model within Azure and update the settings
accordingly.
Release Notes:
- N/A
Add plumbing for hosted projects. This will currently show them if they
exist
but provides no UX to create/rename/delete them.
Also changed the `ChannelId` type to not auto-cast to u64; this avoids
type
confusion if you have multiple id types.
Release Notes:
- N/A
This PR renames the `ZedHttpClient` to `HttpClientWithUrl` to make it
slightly clearer that it still is holding a `dyn HttpClient` as opposed
to being a concrete implementation.
Release Notes:
- N/A
This PR updates the `EventCoalescer` to use the `SystemClock` trait to
abstract over the clock.
This allows us to test the advancement of time without relying on the
caller passing in the current time.
Release Notes:
- N/A
This PR adds a `SystemClock` trait for abstracting away the system
clock.
This allows us to swap out the real system clock with a
`FakeSystemClock` in the tests, thus allowing the fake passage of time.
We're using this in `Telemetry` to better mock the clock for testing
purposes.
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.
This change switches from using async_tungstenite::async_tls to
async_tungstenite::async_std with the async-native-tls feature.
The previous feature, async_tls, used async-tls which wraps rustls.
rustls bundles webpki-roots, which is a copy of Mozilla's root
certificates. These certificates are used by default, and manual
configuration is required to support custom certificates, such as those
required by web security gateways in enterprise environments.
Instead of introducing a new configuration option to Zed,
async-native-tls integrates with the platform-native certificate store
to support enterprise environments out-of-the-box. For MacOS, this adds
support for Security.framework TLS. This integration is provided through
openssl-sys, which is also the SSL certificate provider for isahc, the
library underlying Zed's HTTP client. Making websockets and HTTP
communications use the same SSL provider should keep Zed consistent
operations and make the project easier to maintain.
Release Notes:
- Fixed WebSocket communications using custom TLS certificates
([#4759](https://github.com/zed-industries/zed/issues/4759)).
- Send app version and release stage to collab on connect
- Read the new header on the server
Release Notes:
- Added the ability to collaborate with users on different releases of
Zed.
We're seeing a bit of nonsense on telemetry. Although the checksum seed
isn't secret per-se, it does make sending nonsense a little more effort.
Release Notes:
- N/A
This should prevent a class of bugs where one queries the wrong type of
global, which results in oddities at runtime.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>