Fix bad quote in script/determine-release-channel#20613
Merged
Conversation
notpeter
added a commit
that referenced
this pull request
Nov 13, 2024
ConradIrwin
added a commit
that referenced
this pull request
Dec 17, 2025
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 #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 --> - Fixes #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>
HactarCE
pushed a commit
that referenced
this pull request
Dec 17, 2025
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 #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 --> - Fixes #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>
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
…s#44915) Closes zed-industries#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#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 --> - Fixes zed-industries#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>
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
…s#44915) Closes zed-industries#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#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 --> - Fixes zed-industries#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>
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Feb 15, 2026
…s#44915) Closes zed-industries#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#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 --> - Fixes zed-industries#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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Broke in:
Release Notes: