- Closes#19030
When `%U` is used in desktop entries, file managers pick this and use
it:
- When you right-click a file and choose "Open with..."
- When you drag and drop files onto an application icon
<img
src="https://github.com/user-attachments/assets/ea5aa008-b81c-4f10-9302-b82332f6b174"
width="200px" alt="image">
Adding it to CLI args, changes Flatpak desktop entry `Exec` from:
```diff
- Exec=/usr/bin/flatpak run --branch=master --arch=x86_64 --command=zed dev.zed.ZedDev --foreground
+ Exec=/usr/bin/flatpak run --branch=master --arch=x86_64 --command=zed --file-forwarding dev.zed.ZedDev --foreground @@u %U @@
```
This is Flatpak's way of doing `%U`, by adding `--file-forwarding` and
wrapping arg with `@@u` and `@@`.
Read more below
([source](https://docs.flatpak.org/en/latest/flatpak-command-reference.html)):
> --file-forwarding
>
> If this option is specified, the remaining arguments are scanned, and
all arguments that are enclosed between a pair of '@@' arguments are
interpreted as file paths, exported in the document store, and passed to
the command in the form of the resulting document path. Arguments
between "@@u" and "@@" are considered URIs, and any "file:" URIs are
exported. The exports are non-persistent and with read and write
permissions for the application.
Release Notes:
- Fixed Zed not visible in the "Open with" list in the file manager for
Flatpak.
Closes https://github.com/zed-industries/zed/issues/10196
I think having this action exposed in the editor controls menu, close to
the inline Git Blame option, makes more sense than a more prominent item
somewhere else in the app. Maybe having it there will increase its
discoverability. I myself didn't know this until a few weeks ago! Next
steps would be ensuring the menu exposes its keybindings.
(Quick note about the menu item name: I think maybe "_Git Blame Column_"
would make more sense and feel grammatically more correct, but then we
would have two Git Blame-related options, one with "Git Blame" at the
start (Inline...) and another with "Git Blame" at the end (... Column).
I guess one had to be sacrificed for the sake of consistency 😅.)
<img width="750" alt="Screenshot 2024-11-29 at 12 01 33"
src="https://github.com/user-attachments/assets/2f3324ec-a2f0-4303-9582-714d0ee6bd31">
Release Notes:
- N/A
Closes#19866
This PR supersedes #19228, as #19228 encountered too many merge
conflicts.
After some exploration, I found that for paths with the `\\?\` prefix,
we can safely remove it and consistently use the clean paths in all
cases. Previously, in #19228, I thought we would still need the `\\?\`
prefix for IO operations to handle long paths better. However, this
turns out to be unnecessary because Rust automatically manages this for
us when calling IO-related APIs. For details, refer to Rust's internal
function
[`get_long_path`](017ae1b21f/library/std/src/sys/path/windows.rs (L225-L233)).
Therefore, we can always store and use paths without the `\\?\` prefix.
This PR introduces a `SanitizedPath` structure, which represents a path
stripped of the `\\?\` prefix. To prevent untrimmed paths from being
mistakenly passed into `Worktree`, the type of `Worktree`’s `abs_path`
member variable has been changed to `SanitizedPath`.
Additionally, this PR reverts the changes of #15856 and #18726. After
testing, it appears that the issues those PRs addressed can be resolved
by this PR.
### Existing Issue
To keep the scope of modifications manageable, `Worktree::abs_path` has
retained its current signature as `fn abs_path(&self) -> Arc<Path>`,
rather than returning a `SanitizedPath`. Updating the method to return
`SanitizedPath`—which may better resolve path inconsistencies—would
likely introduce extensive changes similar to those in #19228.
Currently, the limitation is as follows:
```rust
let abs_path: &Arc<Path> = snapshot.abs_path();
let some_non_trimmed_path = Path::new("\\\\?\\C:\\Users\\user\\Desktop\\project");
// The caller performs some actions here:
some_non_trimmed_path.strip_prefix(abs_path); // This fails
some_non_trimmed_path.starts_with(abs_path); // This fails too
```
The final two lines will fail because `snapshot.abs_path()` returns a
clean path without the `\\?\` prefix. I have identified two relevant
instances that may face this issue:
-
[lsp_store.rs#L3578](0173479d18/crates/project/src/lsp_store.rs (L3578))
-
[worktree.rs#L4338](0173479d18/crates/worktree/src/worktree.rs (L4338))
Switching `Worktree::abs_path` to return `SanitizedPath` would resolve
these issues but would also lead to many code changes.
Any suggestions or feedback on this approach are very welcome.
cc @SomeoneToIgnore
Release Notes:
- N/A
Change the "Apply" and "Discard" buttons to match @danilo-leal's design!
Here are some different states:
### Cursor in the first hunk
Now that the cursor is in a particular hunk, we show the "Apply" and
"Discard" names, and the keyboard shortcut. If I press the keyboard
shortcut, it will only apply to this hunk.
<img width="759" alt="Screenshot 2024-11-23 at 10 54 45 PM"
src="https://github.com/user-attachments/assets/68e0f109-9493-4ca2-a99c-dfcbb4d1ce0c">
### Cursor in the second hunk
Moving the cursor to a different hunk changes which buttons get the
keyboard shortcut treatment. Now the keyboard shortcut is shown next to
the hunk that will actually be affected if you press that shortcut.
<img width="749" alt="Screenshot 2024-11-23 at 10 56 27 PM"
src="https://github.com/user-attachments/assets/59c2ace3-6972-4a60-b806-f45e8c25eaae">
Release Notes:
- Restyled Apply/Discard buttons
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
Fix cmd-pipe
Remove redudnant jetbrains/sublime keybinds (these exist as `cmd-{` and `cmd-}` under default vscode keymap) and were broken as part of the recent keybind changes.
Remove excess JSON whitespace from tests to make them more readable.
This PR factors the tool definitions out of the `assistant` crate so
that they can be shared between `assistant` and `assistant2`.
`ToolWorkingSet` now lives in `assistant_tool`. The tool definitions
themselves live in `assistant_tools`, with the exception of the
`ContextServerTool`, which has been moved to the `context_server` crate.
As part of this refactoring I needed to extract the
`ContextServerSettings` to a separate `context_server_settings` crate so
that the `extension_host`—which is referenced by the `remote_server`—can
name the `ContextServerSettings` type without pulling in some undesired
dependencies.
Release Notes:
- N/A
This reverts #20824 and #20899. After adding them last week we came to
the conclusion that the hints are too distracting in everyday use, see
#21128 for more details.
Release Notes:
- N/A
This PR breaks ground on a new `assistant2` crate.
In order to see this new version of the assistant, both of the following
must be true:
1. The `assistant2` feature flag is enabled for your user
- It is **not** currently enabled for all staff.
2. You are running a development build of Zed
The intent here is to enable the folks working on `assistant2` to
incrementally land work onto `main` without breaking use of the current
Assistant for anyone.
<img width="1136" alt="Screenshot 2024-11-23 at 10 46 08 AM"
src="https://github.com/user-attachments/assets/5723a13f-5be1-4486-9460-ead7329ba78e">
Release Notes:
- N/A
This PR overhauls extension registration in order to make it more
modular.
The `extension` crate now contains an `ExtensionHostProxy` that can be
used to register various proxies that the extension host can use to
interact with the rest of the system.
There are now a number of different proxy traits representing the
various pieces of functionality that can be provided by an extension.
The respective crates that provide this functionality can implement
their corresponding proxy trait in order to register a proxy that the
extension host will use to register the bits of functionality provided
by the extension.
Release Notes:
- N/A
This PR merges the `quick_action_bar` crate into the `zed` crate.
We weren't really gaining anything by having it be a separate crate, and
it was introducing an additional step in the dependency graph that was
getting in the way.
It's only ~850 LOC, so the impact on the compilation speed of the `zed`
crate itself is negligible.
Release Notes:
- N/A
This PR extracts the `VimModeSetting` out of the `vim` crate and into
its own `vim_mode_setting` crate.
A number of crates were depending on the entirety of the `vim` crate
just to reference `VimModeSetting`, which was not ideal.
Release Notes:
- N/A
This PR removes the `vcs_menu` dependency from `collab_ui`.
We were only depending on this to call `vcs_menu::init`, which isn't
necessary to do here.
Release Notes:
- N/A
This PR removes the `title_bar` crate's dependency on the `feedback`
crate.
The `feedback::GiveFeedback` action now resides at
`zed_actions::feedback::GiveFeedback`.
`title_bar` now no longer depends on `editor` 🥳
Release Notes:
- N/A
This PR removes the `title_bar` crate's dependency on the
`theme_selector`.
The `theme_selector::Toggle` action now resides at
`zed_actions::theme_selector::Toggle`.
Release Notes:
- N/A
This PR extracts an `auto_update_ui` crate out of the `auto_update`
crate.
This allows `auto_update` to not depend on heavier crates like `editor`,
which in turn allows other downstream crates to start building sooner.
Release Notes:
- N/A
This PR removes the `title_bar` crate's dependency on the
`command_palette`.
The `command_palette::Toggle` action now resides at
`zed_actions::command_palette::Toggle`.
Release Notes:
- N/A
This PR adds a new `language_models` crate to house the various language
model providers.
By extracting the provider definitions out of `language_model`, we're
able to remove `language_model`'s dependency on `editor`, which improves
incremental compilation when changing `editor`.
Release Notes:
- N/A
Use actions defined in zed_actions to interface with that crate instead.
One drawback of this is that we now hide call controls when any modal is
visible (we used to hide them just when ssh modal was deployed).
Release Notes:
- N/A
This PR removes a dependency on the `extensions_ui` from the `title_bar`
crate.
This dependency only existed to reference the `Extensions` action, which
has now been moved to the `zed_actions` crate.
This allows `title_bar` to move up in the crate dependency graph.
Release Notes:
- N/A
Co-Authored-by: Thorsten <thorsten@zed.dev>
Co-Authored-by: Antonio <antonio@zed.dev>
Screenshot:
TODO:
- [x] docs
Release Notes:
- Added inline hints that guide users on how to invoke the inline
assistant and open the assistant panel. (These hints can be disabled by
setting `{"assistant": {"show_hints": false}}`.)
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
This PR adds support for context servers provided by extensions.
To provide a context server from an extension, you need to list the
context servers in your `extension.toml`:
```toml
[context_servers.my-context-server]
```
And then implement the `context_server_command` method to return the
command that will be used to start the context server:
```rs
use zed_extension_api::{self as zed, Command, ContextServerId, Result};
struct ExampleContextServerExtension;
impl zed::Extension for ExampleContextServerExtension {
fn new() -> Self {
ExampleContextServerExtension
}
fn context_server_command(&mut self, _context_server_id: &ContextServerId) -> Result<Command> {
Ok(Command {
command: "node".to_string(),
args: vec!["/path/to/example-context-server/index.js".to_string()],
env: Vec::new(),
})
}
}
zed::register_extension!(ExampleContextServerExtension);
```
Release Notes:
- N/A
Closes #16343Closes#10972
Release Notes:
- (breaking change) On macOS when using a keyboard that supports an
extended Latin character set (e.g. French, German, ...) keyboard
shortcuts are automatically updated so that they can be typed without
`option`. This fixes several long-standing problems where some keyboards
could not type some shortcuts.
- This mapping works the same way as
[macOS](https://developer.apple.com/documentation/swiftui/view/keyboardshortcut(_:modifiers:localization:)).
For example on a German keyboard shortcuts like `cmd->` become `cmd-:`,
`cmd-[` and `cmd-]` become `cmd-ö` and `cmd-ä`. This mapping happens at
the time keyboard layout files are read so the keybindings are visible
in the command palette. To opt out of this behavior for your custom
keyboard shortcuts, set `"use_layout_keys": true` in your binding
section. For the mappings used for each layout [see
here](a890df1863/crates/settings/src/key_equivalents.rs (L7)).
---------
Co-authored-by: Will <will@zed.dev>
This contains the main changes to the extensions crate from #20049. The
primary goal here is removing dependencies that we can't include on the
remote.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
This adds support for [git
worktrees](https://matklad.github.io/2024/07/25/git-worktrees.html). It
fixes the errors that show up (git blame not working) and actually adds
support for detecting git changes in a `.git` folder that's outside of
our path (and not even in the ancestor chain of our root path).
(While working on this we discovered that our `.gitignore` handling is
not 100% correct. For example: we do stop processing `.gitignore` files
once we found a `.git` repository and don't go further up the ancestors,
which is correct, but then we also don't take into account the
`excludesFile` that a user might have configured, see:
https://git-scm.com/docs/gitignore)
Closes https://github.com/zed-industries/zed/issues/19842
Closes https://github.com/zed-industries/zed/issues/4670
Release Notes:
- Added support for git worktrees. Zed can now open git worktrees and
the git status in them is correctly handled.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Bennet <bennet@zed.dev>
This still keeps a telemetry.log for the current session, but not one
file per load of zed.
Closes: #20045
Release Notes:
- Fixed a bug where Zed would create a new temporary file on each boot
for telemetry logs
This PR reverts #20076 to turn the `ThemeRegistry` back into a regular
struct again.
It doesn't actually help us by having it behind a trait.
Release Notes:
- N/A
This PR renames the `extension` crate to `extension_host`.
This is to free up the name so that we can create a smaller-scoped
`extension` crate.
Release Notes:
- N/A
This PR converts the `ThemeRegistry` type into a trait instead of a
concrete implementation.
This allows for the extension store to depend on an abstraction rather
than the concrete theme registry implementation.
We currently have two `ThemeRegistry` implementations:
- `RealThemeRegistry` — this was previously the `ThemeRegistry` and
contains the real implementation of the registry.
- `VoidThemeRegistry` — a null object that doesn't have any behavior.
Release Notes:
- N/A
TODO:
- [x] check that the app version is well formatted for zed.dev
Release Notes:
- N/A
---------
Co-authored-by: Trace <violet.white.batt@gmail.com>
This is the start of a notebook UI for Zed.
`🔔 Note: This won't be useable yet when it is merged! Read below. 🔔`
This is going to be behind a feature flag so that we can merge this
initial PR and then make follow up PRs. Release notes will be produced
in a future PR.
Minimum checklist for merging this:
* [x] All functionality behind the `notebooks` feature flag (with env
var opt out)
* [x] Open notebook files in the workspace
* [x] Remove the "Open Notebook" button from title bar
* [x] Incorporate text style refinements for cell editors
* [x] Rely on `nbformat` crate for parsing the notebook into our
in-memory format
* [x] Move notebook to a `gpui::List`
* [x] Hook up output rendering
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Release Notes:
- Linux: Now skips check which exits with "zed is already running" when
in development mode or when run with `zed-local`, matching the behavior
on Mac and Windows
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This PR adds support for selecting toolchains for a given language (e.g.
Rust toolchains or Python virtual environments) with support for SSH
projects provided out of the box. For Python we piggy-back off of
[PET](https://github.com/microsoft/python-environment-tools), a library
maintained by Microsoft.
Closes#16421Closes#7646
Release Notes:
- Added toolchain selector to the status bar (with initial support for
Python virtual environments)
This removes the old `remote_server { "download_binary_on_host": bool }`
field and replaces it with a `upload_binary: bool` on every
`ssh_connection`.
@ConradIrwin it compiles, it connects, but I haven't tested it really
yet
Release Notes:
- N/A
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This restores all the init behaviour into main again. This means we
never need to call init_ui (and so we can't call it more than once).
Release Notes:
- (Nightly only) fixes a panic when using the cli to open another file
in a running zed.
