Repository navigation
Let the editing-mode label follow its own editor lifetime - #1761
Merged
Merged
Conversation
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
|
debt-src at bbcd60b blocks on 2 lines: |
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
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.
Fix the label's lifetime
The retained ChannelPrompt traceback came from PromptTextArea's deferred callback querying a footer sibling. The editor was mounted; the sibling label was not. Checking the editor again cannot make that label exist.
Each PromptTextArea now creates and owns its original EditingModeLabel. Shared Prompt.compose mounts that exact label in the same InfoBar. The existing mode/focus hook updates its owned object directly; no cross-sibling DOM query or retry remains. This covers native, mailbox and channel prompts through the same inherited composition. Recomposition gives each editor its own label, so an old callback cannot update another editor's label.
An initial reactive-watch attempt was corrected on this PR: Neovim mutates its mode object in place and uses the existing show_editing_mode hook. The final change preserves that hook, the original after-refresh call, display calculation and focus behavior. No new flag, event family, cache or silent lookup guard.
Native NRA plans:
.verification/editing-mode-label/. Final source compiles and diff check passes.Original focused controls — red, not claimed green
Two original native-editor/channel controls ran. Both stopped before their final assertions at
NEOVIM STARTING; 2 failed in 35.55s. The final direct-owner version was checked with the same two controls: 2 failed in 37.29s at the same startup boundary.The shared
/home/ts/code/projects/agent-comms/.venvhas no preparedshare/toad/neovim/0.12.4payload. NeovimHost startsNeovim().command(), which uses sys.prefix and refuses that missing prepared executable. No dependency was installed around the declaration. These results do not establish end-to-end Neovim behavior. Source tracing establishes removal of the failing DOM lookup while preserving the original mode-update hook. No additional app test or profile is running; the exact helper PIDs 1119158 and 1119298 have exited.Retained logs:
/home/ts/.cache/agent-scratch/codex-latency/editing-mode-{label,owned-label}-check.log. Landing as a recoverable owner fix; installation joins the coordinated batch, no competing installer.Other reported error
The exact command_catalog WorkerFailed trace also ends in RosterSidebarRead._cached_model, already fixed in Core #4670. It does not establish a separate registry_for defect.