Closes#26424
Supersedes #35328
Originally, `git::blame` uses its own `ParsedCommitMessage` as the
source for the commit information, including the PR section. This
changes unifies this with `git::repository` and `git_ui::git_panel` by
moving this and some other commit-related structs to `git::commit`
instead, and making both `git_ui::blame_ui` and `git_ui::git_panel` pull
their information from these structs.
Release notes :
- (Let's Git Together) Fixed the commit tooltip in the git panel not
showing information like avatars.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This PR ensures truncation works for the file paths, which should set up
the stage for when the new GPUI `truncation_start` method lands
(https://github.com/zed-industries/zed/pull/45122) so that we can use
for them. In the process of doing so and figuring it out why it wasn't
working as well before, I noticed some opportunities to clean up some UI
code: removing unnecessary styles, making the file easier to navigate
given all of the different UI conditions, etc.
Note: You might notice a subtle label flashing that comes with the label
truncation and that's a standalone GPUI bug that's also visible in other
surface areas of the app. I don't think it should block these changes
here as it's something we should fix on its own...
Release Notes:
- N/A
Also adjust the code for streaming tool use to always use a
rewrite_section; remove insert_here entirely.
Release Notes:
- N/A
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Related to
- #44407
This PR further improves performance for regex hyperlink finding by
eliminating unnecessary regex matching. Currently, we repeatedly search
for matches from the start of the line until the match contains the
hovered point. This is only required to support custom regexes which
match strings containing spaces, with multiple matches on a single line.
This isn't actually a useful scenario, and is no longer supported. This
PR changes to only search twice, the first match starting from the start
of the line, and the hovered word (space-delimited). The most dramatic
improvement is for long lines with many words.
In addition to the above changes, this PR:
- Adds test for the scenarios from #44407 and #44510
- Simplifies the logic added in #44407
Performance measurements
For the scenario from #44407, this improves the perf test's iteration
time from 1.22ms to 0.47ms.
main:
| Branch | Command | Iter/sec | Mean [ms] | SD [ms] | Iterations |
Importance (weight) |
|:---|:---|---:|---:|---:|---:|---:|
| main |
terminal_hyperlinks::tests::path::perf::pr_44407_hyperlink_benchmark |
819.64 | 937.60 | 2.20 | 768 | average (50) |
| this PR |
terminal_hyperlinks::tests::path::perf::pr_44407_hyperlink_benchmark |
2099.79 | 1463.20 | 7.20 | 3072 | average (50) |
Release Notes:
- terminal: Improve path hyperlink performance for long lines
This PR introduces support for Next Edit Suggestions while doing away
with calling legacy endpoints. In the process we've also removed support
for cycling completions, as NES will give us a single prediction, for
the most part.
Closes#30124
Release Notes:
- Zed now supports Copilot's [Next Edit
Suggestions](https://code.visualstudio.com/blogs/2025/02/12/next-edit-suggestions).
## Summary
Addresses #16965
This PR adds support for **opening and saving** files with legacy
encodings (non-UTF-8).
Previously, Zed failed to open files encoded in Shift-JIS, EUC-JP, Big5,
etc., displaying a "Could not open file" error screen. This PR
implements automatic encoding detection upon opening and ensures the
original encoding is preserved when saving.
## Implementation Details
1. **Worktree (Loading)**:
* Updated `load_file` to use `chardetng` for automatic encoding
detection.
* Files are decoded to UTF-8 internal strings for editing, while
preserving the detected `Encoding` metadata.
2. **Language / Buffer**:
* Added an `encoding` field to the `Buffer` struct to store the detected
encoding.
3. **Worktree (Saving)**:
* Updated `write_file` to accept the stored encoding.
* **Performance Optimization**:
* **UTF-8 Path**: Uses the existing optimized `fs.save` (streaming
chunks directly from Rope), ensuring no performance regression for the
vast majority of files.
* **Legacy Encoding Path**: Implemented a fallback that converts the
Rope to a contiguous `String/Bytes` in memory, re-encodes it to the
target format (e.g., Shift-JIS), and writes it to disk.
* *Note*: This fallback involves memory allocation, but it is necessary
to support legacy encodings without refactoring the `fs` crate's
streaming interfaces.
## Changes
- `crates/worktree`:
- Add dependencies: `encoding_rs`, `chardetng`.
- Update `load_file` to detect encoding and decode content.
- Update `write_file` to handle re-encoding on save.
- `crates/language`: Add `encoding` field and accessors to `Buffer`.
- `crates/project`: Pass encoding information between Worktree and
Buffer.
- `crates/vim`: Update `:w` command to use the new `write_file`
signature.
## Verification
I validated this manually using a Rust script to generate test files
with various encodings.
**Results:**
* ✅ **Success (Opened & Saved correctly):**
* **Japanese:** `Shift-JIS` (CP932), `EUC-JP`, `ISO-2022-JP`
* **Chinese:** `Big5` (Traditional), `GBK/GB2312` (Simplified)
* **Western/Unicode:** `Windows-1252` (CP1252), `UTF-16LE`, `UTF-16BE`
* ⚠️ **limitations (Detection accuracy):**
* Some specific encodings like `KOI8-R` or generic `Latin1` (ISO-8859-1)
may partially display replacement characters (`?`) depending on the file
content length. This is a known limitation of the heuristic detection
library (`chardetng`) rather than the saving logic.
Release Notes:
- Added support for opening and saving files with legacy encodings
(Shift-JIS, Big5, etc.)
---------
Co-authored-by: CrazyboyQCD <53971641+CrazyboyQCD@users.noreply.github.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
I could not find any related issue, but at least I want to use the git
panel like this :)
Being used to `lazygit`, this PR makes navigation of the git panel more
similar to the CLI tool.
Instead of selecting -> enter'ing for skimming each file, I just want to
move between the files in the git panel and have the diff multibuffer
advance to the appropriate file. This also adheres to the behavior of
the outline panel, which I like better.
If the multibuffer is not active, it behaves same as before (just
selecting the file in the panel, nothing else).
I did not modify existing `menu::Select*` actions in case anybody still
prefers previous behavior.
https://github.com/user-attachments/assets/2d1303d4-50c8-4500-ab3b-302eb7d4afda
Release Notes:
- Improved navigation of the git panel, by advancing the "Uncommitted
Changes" multibuffer to the current selected file. To restore the old
behavior, you can bind `up` and `down` to `menu::SelectPrevious` and
`menu::SelectNext` under the `GitPanel` context in your keymap.
Co-authored-by: Cole Miller <cole@zed.dev>
Fix broken LICENSE-GPL symlink that was pointing to itself instead of
the LICENSE-GPL file in the root of the repo.
It caused jujutsu to freak out and made it impossible to work with the
repo using it without switching to raw git:
```
Internal error: Failed to check out commit 22d04a82b119882e7aed88fb422430367c4df5f9
Caused by:
1: Failed to validate path /Users/aqrln/git/zed/crates/agent_ui_v2/LICENSE-GPL
2: Too many levels of symbolic links (os error 62)
```
Release Notes:
- N/A
The below memory leaks were caused by failing to release reference
counted resources. I confirmed using instruments that my changes stopped
the leaks from occurring.
- System prompts
- Screen capturing
- loading font families
There were also two memory leaks I found from some of our dependencies
that I made PRs to fix
- https://github.com/RustAudio/coreaudio-rs/pull/147
- https://github.com/servo/core-foundation-rs/pull/746
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/44887
Trims the worktree trust mechanism to the actual `worktree`s, so now
"global", workspace-level things like `prettier`, `NodeRuntime`,
`copilot` and global MCP servers are considered as "trusted" a priori.
In the future, a separate mechanism for those will be considered and
added.
Release Notes:
- N/A
Closes #ISSUE
Problem:
- The status bar’s pending keystroke indicator (shown next to --NORMAL--
in Vim mode) didn’t clear when focus moved to another context, e.g.
hitting g in the editor then clicking the Git panel. The keymap state
correctly canceled the prefix, but observers that render the indicator
never received a “pending input changed” notification, so the UI kept
showing stale prefixes until a new keystroke occurred.
Fix:
- The change introduces a `pending_input_changed_queued` flag and a new
helper `notify_pending_input_if_needed` which will flushes the queued
notification as soon as we have an App context. The
`pending_input_changed` now resets the flag after notifying subscribers.
Before:
https://github.com/user-attachments/assets/7bec4c34-acbf-42bd-b0d1-88df5ff099aa
After:
https://github.com/user-attachments/assets/2264dc93-3405-4d63-ad8f-50ada6733ae7
Release Notes:
- Fixed: pending keybinding prefixes on the status bar now clear
immediately when focus moves to another panel or UI context.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Fixes#42668
When clicking 'Configure' to enter a settings subpage, focus was being
lost because push_sub_page only called cx.notify() without managing
focus. Similarly, pop_sub_page had the same issue when navigating back.
This fix:
- Adds window parameter to push_sub_page and pop_sub_page
- Focuses the content area when entering/leaving subpages
- Resets scroll position when entering a subpage
Release Notes:
- Fixed a bug that prevented keyboard navigation in the settings window.
Release Notes:
- Improved display map rendering performance with many lines in the the multi-buffer.
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Cole Miller <cole@zed.dev>
We recently added this `InlineCode` component but I'd forgotten that
many months ago I also introduced an `inline_code` method to the Label
component which does the same thing. That means we don't need a
standalone component at all!
Release Notes:
- N/A
Some refactoring I ran into while working on automatic Markdown list
continuation on newline.
This PR:
- Moves `comment_delimiter` and `documentation_delimiter` computation
outside of newline method.
- Adds `NewlineFormatting`, which holds info about how newlines affect
indentation and other formatting we need.
- Moves newline-specific methods into the new `NewlineFormatting`
struct.
Release Notes:
- N/A
Add support for `zed://git/commit/<path-to-repo>#<sha>` (**EDIT:** now
changed to `zed://git/commit/<sha>?repo=<path>`) URI scheme to access
the git commit view
implement parsing and handling of git commit URIs to navigate directly
to commit views from external links. the main use case for me is to use
OSC8 hyperlinks to link from a git sha into zed. this allows me e.g. to
easily navigate from a terminal into zed
**questions**
- is this URI scheme appropriate? it was the first one i thought of, but
wondering if `?ref=<some sha>` might make more sense – the git/commit
namespace was also an equally arbitrary choice
<details>
<summary>video demo showing navigation from zed's built in
terminal</summary>
https://github.com/user-attachments/assets/18ad7e64-6b39-44b2-a440-1a9eb71cd212
</details>
<details>
<summary>video demo showing navigation from ghostty to zed's commit
view</summary>
https://github.com/user-attachments/assets/1825e753-523f-4f98-b59c-7188ae2f5f19
</details>
Release Notes:
- Added support for `zed://git/commit/<sha>?repo=<path>` URI scheme to
access the git commit view
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Previously, the list of edit files had a double axis scroll issue
because the list itself scrolled vertically and each file row would
scroll horizontally, causing a bad UX. The horizontal scroll intention
was so that you could see the whole path, but I've included it in the
tooltip in case it becomes obscured due to a small panel width.
<img width="500" height="666" alt="Screenshot 2025-12-17 at 11 24@2x"
src="https://github.com/user-attachments/assets/ea87236d-f5c6-475a-bf66-1afae7a6ca05"
/>
Release Notes:
- agent: N/A
Fixes an issue where we would update the imports after a file rename in
TypeScript, but those changes wouldn't surface anywhere until those
buffers were manually opened
(https://github.com/zed-industries/zed/issues/35930#issuecomment-3366852945).
In https://github.com/zed-industries/zed/pull/36681 we already added
support for opening a multibuffer with edits, but vtsls has a different
flow for renames.
Release Notes:
- Files with updated imports now open in a multibuffer when renaming or
moving TypeScript or JavaScript files
Closes#35930
When a TypeScript file is renamed or moved, vtsls can automatically
update the imports in other files. It pops up a message with the option
to always automatically update imports. This choice would previously
only be remembered for the current session and would pop up again after
a restart.
Now we persist that choice to the vtsls LSP settings in Zed, so that it
remembers across editor sessions.
Release Notes:
- When renaming a TypeScript or JavaScript file, the selected option to
automatically update imports will now be remembered across editor
sessions.
Relevant for Nightly Users only, follow up to #45004.
In case you use nightly this will break preview/stable since
deserialisation will fail. Shipping this to Nightly so that staff does
not run into this issue. We can revert this PR in the following days.
I'll make a follow up PR which only stores the prompt in the database in
case you customise it.
Release Notes:
- N/A
Reverts https://github.com/zed-industries/zed/pull/44933.
It turns out that if you're copying agent responses to paste it anywhere
else that isn't the message editor (e.g., for a follow up prompt),
getting Markdown formatting is helpful. However, with the revert, the
underlying issue in https://github.com/zed-industries/zed/issues/42958
remains, so I'll reopen that issue, unfortunately.
Release Notes:
- N/A
Closes#33018
### Problem
When opening a `PopoverMenu` or `RightClickMenu`, the pane's tab bar
buttons would flicker (disappear for a couple frames then reappear).
This happened because:
1. The menu is created and `window.focus()` was called immediately
2. However, menus are rendered using `deferred()`, so their focus
handles aren't connected in the dispatch tree until after the deferred
draw callback runs
3. When the pane checks `has_focus()`, it calls `contains_focused()`
which walks up the focus hierarchy — but the menu's focus handle isn't
linked yet
4. `has_focus()` returns false → tab bar buttons disappear
5. Next frame, the menu is rendered and linked → `has_focus()` returns
true → buttons reappear
### Solution
Delay the focus transfer by 2 frames using nested `on_next_frame()`
calls before focusing the menu.
**Why 2 frames instead of 1?**
The frame lifecycle in GPUI runs `next_frame_callbacks` BEFORE `draw()`:
```
on_request_frame:
1. Run next_frame_callbacks
2. window.draw() ← menu rendered here via deferred()
3. Present
```
So:
- **Frame 1**: First `on_next_frame` callback runs, queues second
callback. Then `draw()` renders the menu and connects its focus handle
to the dispatch tree.
- **Frame 2**: Second `on_next_frame` callback runs and focuses the
menu. Now the focus handle is connected (from Frame 1's draw), so
`contains_focused()` returns true.
With only 1 frame, the focus would happen BEFORE `draw()`, when the
menu's focus handle isn't connected yet.
This follows the same pattern established in b709996ec6 which fixed the
identical issue for the editor's `MouseContextMenu`.
Closes #ISSUE
This PR is rather a nice to have change than anything critical, so
review priority should remain low.
Switch to using `semver::Version` for representing node binary and npm
package versions. This is in an effort to root out implicit behavior and
improve type safety when interacting with the `node_runtime` crate by
catching invalid versions where they appear. Currently Zed may
implicitly assume the current version is correct, or always install the
newest version when a invalid version is passed. `semver::Version` also
doesn't require the heap, which is probably more of a fun fact than
anything useful.
`npm_install_packages` still takes versions as a `&str`, because
`latest` can be used to fetch the latest version on npm. This could
likely be made into an enum as well, but would make the PR even larger.
I tested changes with some node based language servers and external
agents, which all worked fine. It would be nice to have some e2e tests
for node. To be safe I'd put it on nightly after a Wednesday release.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#44624
Before this change, white space would be trimmed from word diff ranges.
Users found this behavior confusing, so we're changing it to be more
inline with how GitHub treats whitespace in their word diffs.
Release Notes:
- git: Word diffs won't filter out pure whitespace diffs now
Both `test_miniquotes_object` and `test_minibrackets_object` rely on
tree-sitter parsing for `MultiBufferSnapshot.bracket_ranges` to find
quote/bracket pairs. The `VimTestContext.set_state` call eventually
triggers async tree-sitter parsing, but `run_until_parked` doesn't
guarantee parsing completion.
We suspect this is what might be causing the flakiness on Windows, as
the syntax might not yet be parsed when the
`VimTestContext.simulate_keystrokes` call is made, so there's no bracket
pairs returned.
This commit adds an explicit await call on `Bufffer.parsing_idle` after
each `VimTestContext.set_state` call, to ensure tree-sitter parsing
completes before simulating keystrokes.
Release Notes:
- N/A
Obviously this doesn't do too much without having an actual windows
server binary for the remote side, but it does at least improve the
error message as right now we will complain about `uname` not being a
valid powershell command.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#45033
This bug happened because the deletion icon would use the selected entry
index to choose what branch to delete. This works for all cases except
when hovering on an entry, so the fix was passing in the entry index to
the deletion button on_click handler.
I also disabled the deletion button from working if a branch is HEAD,
because it's an illegal operation to delete a branch a user is currently
on.
Finally, I made WeakEntity<Workspace> a non-optional field on
`BranchList` because a workspace should always be present, and it's used
to show toast notifications when a git operation fails. The popover view
wouldn't have a workspace before, so users wouldn't get error messages
when a git operation failed in that view.
Release Notes:
- git: Fix bug where branch list deletion button would delete the wrong
branch
Closes#43722
Release Notes:
- Fixed an issue where auto-indentation didn’t work correctly for Python
code blocks in Markdown.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Fixes the hang introduced in #44995 (which was reverted in #45011) and
re-enables the optimization.
## Background
PR #44995 introduced an optimization to skip rendering lines that are
clipped by parent containers (e.g., when a large AutoHeight editor is
inside a scrollable List). This significantly improved performance for
large diffs in the Agent Panel.
However, #45011 reverted this change because it caused the main thread
to hang for 100+ seconds in certain scenarios, requiring a force quit to
recover.
## Root Cause
The original analysis in #45011 suggested that visible_bounds wasn’t
being intersected properly, but that was incorrect—the intersection via
with_content_mask works correctly. The actual bug: when an editor is
positioned above the visible viewport (e.g., scrolled past in a List),
the clipping calculation produces a start_row that exceeds max_row:
1. Editor’s bounds.origin.y becomes very negative (e.g., -10000px)
2. After intersection, visible_bounds.origin.y is at the viewport top
(e.g., 0)
3. clipped_top_in_lines = (0 - (-10000)) / line_height = huge number
4. start_row = huge number, but end_row is clamped to max_row
5. This creates an invalid range where start_row > end_row
This caused two different failures depending on build mode:
- Debug mode: Panic from subtraction overflow in
Range<DisplayRow>::len()
- Release mode: Integer wraparound causing blocks_in_range to enter an
infinite loop (the 100+ second hang)
## Fix
Simply clamp start_row to max_row, ensuring the row range is always
valid:
```rs
let start_row = cmp::min(
DisplayRow((scroll_position.y + clipped_top_in_lines).floor() as u32),
max_row,
);
```
## Testing
Added a regression test that draws an editor at y=-10000 to simulate an
editor that’s been scrolled past in a List. This would panic in debug
mode (and hang in release mode) before the fix.
Release Notes:
- Improved agent panel performance when rendering large diffs.
0.0.2 is not a pre-release artifact unlike the previous one, so our
version fetch ignored it.
Fixes https://github.com/zed-industries/zed/issues/45061
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Remove some intermediate allocations when reconstructing text or wrapped
text from a `TextLayout`. Currently creates a intermediate `Vec<String>`
which gets joined, when you could join an `impl Iterator<Item = &str>`
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#20613
Release Notes:
- Fixed: New windows no longer flicker between "Open a file or project
to get started" and an empty editor.
---
When opening a new window (`cmd-shift-n`), the window rendered showing
the empty state message before the editor was created, causing a visible
flicker.
**Changes:**
- Modified `Workspace::new_local` to accept an optional `init` callback
that executes inside the window build closure
- The init callback runs within `cx.new` (the `build_root_view`
closure), before `window.draw()` is called for the first render
- Changed the NewWindow action handler to use
`Project::create_local_buffer()` (synchronous) instead of
`Editor::new_file()` (asynchronous)
- Updated `open_new` to pass the editor creation callback to `new_local`
- All other `new_local` call sites pass `None` to maintain existing
behavior
**Key Technical Detail:**
The window creation sequence in `cx.open_window()` is:
1. `build_root_view` closure is called (creates workspace via `cx.new`)
2. `window.draw(cx)` is called (first render)
3. `open_window` returns
The fix uses `Project::create_local_buffer()` which creates a buffer
**synchronously** (returns `Entity<Buffer>` directly), rather than
`Editor::new_file()` which is asynchronous (calls
`project.create_buffer()` which returns a `Task`). The editor is created
from this buffer inside the `cx.new` closure (step 1), ensuring it
exists before step 2 renders the first frame.
**Before:**
```rust
let task = Workspace::new_local(Vec::new(), app_state, None, env, cx);
cx.spawn(async move |cx| {
let (workspace, _) = task.await?; // Window already drawn
workspace.update(cx, |workspace, window, cx| {
Editor::new_file(workspace, ...) // Async - editor not present for first render
})?;
})
```
**After:**
```rust
cx.open_window(options, {
move |window, cx| {
cx.new(|cx| {
let mut workspace = Workspace::new(...);
// Create buffer synchronously, then create editor
if let Some(init) = init {
init(&mut workspace, window, cx); // Uses create_local_buffer (sync)
}
workspace
})
}
})?
```
The editor is now part of the workspace before the window's first frame
is rendered, eliminating the flicker.
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>Opening a new window flickers before opening an empty
buffer</issue_title>
> <issue_description>### Check for existing issues
>
> - [x] Completed
>
> ### Describe the bug / provide steps to reproduce it
>
> Opening a new window, with e.g. `cmd-shift-n`, flickers for a fraction
of a second. The new window first shows the startup page, "Open a file
or project to get started.". Then, a frame or two later, a new empty
buffer opens.
>
> Not sure if I'm sensitive or something but these kinds of flashes can
knock me out of focus/flow pretty easily.
>
> It'd be great to either have the empty buffer open from the first
frame, or to have an option to simply not open that empty buffer when a
new window is opened.
>
> ### Zed Version and System Specs
>
> Zed: v0.170.4 (Zed)
> OS: macOS 14.6.1
> Memory: 36 GiB
> Architecture: aarch64
>
> ### If applicable, add screenshots or screencasts of the incorrect
state / behavior
>
>
https://github.com/user-attachments/assets/6d9ba791-8a02-4e13-857c-66a33eb0905b
>
> ### If applicable, attach your Zed.log file to this issue.
>
> N/A</issue_description>
>
> <agent_instructions>We should make sure that the window is created in
the correct state, and not have an intermediate render before the editor
opens.</agent_instructions>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> <comment_new><author>@ConradIrwin</author><body>
> Ugh, no. I don't believe I never noticed this before, but now I can't
unsee it :s
>
> If you'd like to pair on this: https://cal.com/conradirwin/pairing,
otherwise I'll see if I get around to it.</body></comment_new>
> <comment_new><author>@ConradIrwin</author><body>
> Yeah... I wonder if that can be a preview tab or something. It's nice
when you want it, but not so nice when you don't.
>
> Fixing this will also make zed-industries/zed#33334 feel much
smoother.</body></comment_new>
> <comment_new><author>@zelenenka</author><body>
> @robinplace do you maybe have an opportunity to test it with the
latest stable version, 0.213.3?</body></comment_new>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixeszed-industries/zed#23742
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: ConradIrwin <94272+ConradIrwin@users.noreply.github.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
