Update tree-sitter-highlight requirement from 0.24.7 to 0.25.3 - #4
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Update tree-sitter-highlight requirement from 0.24.7 to 0.25.3#4dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Updates the requirements on [tree-sitter-highlight](https://github.com/tree-sitter/tree-sitter) to permit the latest version. - [Release notes](https://github.com/tree-sitter/tree-sitter/releases) - [Commits](tree-sitter/tree-sitter@v0.24.7...v0.25.3) --- updated-dependencies: - dependency-name: tree-sitter-highlight dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/cargo/tree-sitter-highlight-0.25.3
branch
November 19, 2025 06:36
sinelaw
pushed a commit
that referenced
this pull request
Mar 6, 2026
Key changes since Feb 26: - 10 previously triaged issues confirmed CLOSED (including our #1, #2, #4 bug priorities and #1 enhancement priority) - 9 new issues added (#1128-#1202) - Corrected #716 status (still open, not closed as previously stated) - Added new duplicate groups: Deno/multi-LSP, C# naming, clipboard/OSC52 - New sections: Packaging/Distribution, Language/Syntax support - Added velocity tracking table showing triage effectiveness - #1054 still open but reporter confirmed fix - should be closed https://claude.ai/code/session_01BsP93dzqKSGyLSbMRZ9LYS
sinelaw
pushed a commit
that referenced
this pull request
Apr 4, 2026
Replace direct std::fs::metadata and std::process::Command usage in check_git_index_mtime / resolve_git_index with the proper traits: - resolve_git_index: uses ProcessSpawner (works over SSH for remote) - git index mtime check: uses FileSystem.metadata() in background thread alongside directory metadata checks (non-blocking) This follows CONTRIBUTING.md rules #4 and #5: never use std::fs or std::process::Command directly — use the FileSystem and ProcessSpawner traits so features work transparently on remote hosts. https://claude.ai/code/session_01VxhvsKhfDTK6PjBWUqWjvJ
sinelaw
pushed a commit
that referenced
this pull request
Apr 5, 2026
Replace direct std::fs::metadata and std::process::Command usage in check_git_index_mtime / resolve_git_index with the proper traits: - resolve_git_index: uses ProcessSpawner (works over SSH for remote) - git index mtime check: uses FileSystem.metadata() in background thread alongside directory metadata checks (non-blocking) This follows CONTRIBUTING.md rules #4 and #5: never use std::fs or std::process::Command directly — use the FileSystem and ProcessSpawner traits so features work transparently on remote hosts. https://claude.ai/code/session_01VxhvsKhfDTK6PjBWUqWjvJ
sinelaw
pushed a commit
that referenced
this pull request
Apr 26, 2026
Bug #4 from DEVCONTAINER_USABILITY_TEST_2026-04-26.md (L171, High, scoped to the notify half): the spec says `portsAttributes.<port>.onAutoForward: "notify"` should surface a notification when the port is auto-forwarded. The plugin read the attribute (used it for the picker / panel labels) but never acted on it. Task 3 of the usability report saw a published port with `notify` configured and got no toast. Fix: hook the new `authority_changed` event from Bug #1 — when we transition into `Container:*` mode, run `runAutoForwardSweep`, which calls `gatherForwardedPortRows` (existing code, queries `docker port <id>`), filters for entries that are configured AND bound AND opted into `notify`, and fires `editor.setStatus(t("status.port_forwarded", ...))` for each. Track a `notifiedPorts: Set<key>` so the same binding doesn't re-fire mid-session; clear it on detach so a fresh attach re-notifies. Out of scope: actually publishing ports that docker hasn't already mapped. The spec's "auto-forward" piece — VS Code-style host-side userspace forwarder — is much larger work and gets a separate effort. Today the toast fires for ports that ARE published (via `appPort` / runArgs / external mapping), which is the visible piece the user complained about. Test: `auto_forward_notify_fires_for_configured_port`. Drives a workspace with `forwardPorts: [9000]` + `notify`, sets `FAKE_DC_PORTS=9000` so the fake docker reports the binding, attaches via the fake CLI, asserts `Port 9000 forwarded` lands in the rendered screen.
sinelaw
pushed a commit
that referenced
this pull request
Apr 26, 2026
Bug #4 from DEVCONTAINER_USABILITY_TEST_2026-04-26.md (L171, High, scoped to the notify half): the spec says `portsAttributes.<port>.onAutoForward: "notify"` should surface a notification when the port is auto-forwarded. The plugin read the attribute (used it for the picker / panel labels) but never acted on it. Task 3 of the usability report saw a published port with `notify` configured and got no toast. Fix: hook the new `authority_changed` event from Bug #1 — when we transition into `Container:*` mode, run `runAutoForwardSweep`, which calls `gatherForwardedPortRows` (existing code, queries `docker port <id>`), filters for entries that are configured AND bound AND opted into `notify`, and fires `editor.setStatus(t("status.port_forwarded", ...))` for each. Track a `notifiedPorts: Set<key>` so the same binding doesn't re-fire mid-session; clear it on detach so a fresh attach re-notifies. Out of scope: actually publishing ports that docker hasn't already mapped. The spec's "auto-forward" piece — VS Code-style host-side userspace forwarder — is much larger work and gets a separate effort. Today the toast fires for ports that ARE published (via `appPort` / runArgs / external mapping), which is the visible piece the user complained about. Test: `auto_forward_notify_fires_for_configured_port`. Drives a workspace with `forwardPorts: [9000]` + `notify`, sets `FAKE_DC_PORTS=9000` so the fake docker reports the binding, attaches via the fake CLI, asserts `Port 9000 forwarded` lands in the rendered screen.
sinelaw
pushed a commit
that referenced
this pull request
Apr 27, 2026
Bug #4 from DEVCONTAINER_USABILITY_TEST_2026-04-26.md (L171, High, scoped to the notify half): the spec says `portsAttributes.<port>.onAutoForward: "notify"` should surface a notification when the port is auto-forwarded. The plugin read the attribute (used it for the picker / panel labels) but never acted on it. Task 3 of the usability report saw a published port with `notify` configured and got no toast. Fix: hook the new `authority_changed` event from Bug #1 — when we transition into `Container:*` mode, run `runAutoForwardSweep`, which calls `gatherForwardedPortRows` (existing code, queries `docker port <id>`), filters for entries that are configured AND bound AND opted into `notify`, and fires `editor.setStatus(t("status.port_forwarded", ...))` for each. Track a `notifiedPorts: Set<key>` so the same binding doesn't re-fire mid-session; clear it on detach so a fresh attach re-notifies. Out of scope: actually publishing ports that docker hasn't already mapped. The spec's "auto-forward" piece — VS Code-style host-side userspace forwarder — is much larger work and gets a separate effort. Today the toast fires for ports that ARE published (via `appPort` / runArgs / external mapping), which is the visible piece the user complained about. Test: `auto_forward_notify_fires_for_configured_port`. Drives a workspace with `forwardPorts: [9000]` + `notify`, sets `FAKE_DC_PORTS=9000` so the fake docker reports the binding, attaches via the fake CLI, asserts `Port 9000 forwarded` lands in the rendered screen.
sinelaw
pushed a commit
that referenced
this pull request
May 12, 2026
…ed stacking)
The original `issue_1_click_stacks_plugin_popup_and_lsp_servers_popup`
test pre-pushed a popup to the buffer-local `active_state().popups`,
which caught one half of the bug. But the embedded `rust-lsp.ts`
plugin's `editor.showActionPopup` actually lands on the editor-wide
`global_popups` stack (`handle_show_action_popup` →
`self.global_popups.show(popup_obj)`). My earlier fix only checked
`active_state().popups`, so:
- the LSP Servers popup still gets built on `active_state().popups`
when the click happens
- the plugin's async-arriving `ShowActionPopup` lands on
`global_popups` a tick later
- the user sees two popups for one click
Add `issue_1_plugin_popup_lands_on_global_popups_after_lsp_servers_popup`
that exercises this exact order: call `show_lsp_status_popup` first,
then push a plugin popup via `handle_plugin_command`. Assert the total
across both stacks is 1.
Issue 4 is the "if I click many times this popup sometimes stacks -
dismissing it I see the same popup underneath" report.
`handle_show_action_popup` uses `global_popups.show()` (plain) instead
of `show_or_replace()`, so repeating the same `popup_id` stacks
identical popups. Add `issue_4_repeated_plugin_action_popup_pushes_stack
_instead_of_replace` that pushes three popups with the same id and
asserts only one remains.
Both tests fail today, demonstrating the bugs. The 5 pre-existing
LSP-indicator-click bug tests still pass — these two are additions,
not edits.
Adds `pub fn Editor::global_popups()` as a read-only accessor for
tests; the field itself stays `pub(crate)`.
https://claude.ai/code/session_01EHPvWNSvRrhYffJtRTebB7
sinelaw
pushed a commit
that referenced
this pull request
May 12, 2026
…ed stacking)
The original `issue_1_click_stacks_plugin_popup_and_lsp_servers_popup`
test pre-pushed a popup to the buffer-local `active_state().popups`,
which caught one half of the bug. But the embedded `rust-lsp.ts`
plugin's `editor.showActionPopup` actually lands on the editor-wide
`global_popups` stack (`handle_show_action_popup` →
`self.global_popups.show(popup_obj)`). My earlier fix only checked
`active_state().popups`, so:
- the LSP Servers popup still gets built on `active_state().popups`
when the click happens
- the plugin's async-arriving `ShowActionPopup` lands on
`global_popups` a tick later
- the user sees two popups for one click
Add `issue_1_plugin_popup_lands_on_global_popups_after_lsp_servers_popup`
that exercises this exact order: call `show_lsp_status_popup` first,
then push a plugin popup via `handle_plugin_command`. Assert the total
across both stacks is 1.
Issue 4 is the "if I click many times this popup sometimes stacks -
dismissing it I see the same popup underneath" report.
`handle_show_action_popup` uses `global_popups.show()` (plain) instead
of `show_or_replace()`, so repeating the same `popup_id` stacks
identical popups. Add `issue_4_repeated_plugin_action_popup_pushes_stack
_instead_of_replace` that pushes three popups with the same id and
asserts only one remains.
Both tests fail today, demonstrating the bugs. The 5 pre-existing
LSP-indicator-click bug tests still pass — these two are additions,
not edits.
Adds `pub fn Editor::global_popups()` as a read-only accessor for
tests; the field itself stays `pub(crate)`.
https://claude.ai/code/session_01EHPvWNSvRrhYffJtRTebB7
sinelaw
pushed a commit
that referenced
this pull request
May 12, 2026
…ed stacking)
The original `issue_1_click_stacks_plugin_popup_and_lsp_servers_popup`
test pre-pushed a popup to the buffer-local `active_state().popups`,
which caught one half of the bug. But the embedded `rust-lsp.ts`
plugin's `editor.showActionPopup` actually lands on the editor-wide
`global_popups` stack (`handle_show_action_popup` →
`self.global_popups.show(popup_obj)`). My earlier fix only checked
`active_state().popups`, so:
- the LSP Servers popup still gets built on `active_state().popups`
when the click happens
- the plugin's async-arriving `ShowActionPopup` lands on
`global_popups` a tick later
- the user sees two popups for one click
Add `issue_1_plugin_popup_lands_on_global_popups_after_lsp_servers_popup`
that exercises this exact order: call `show_lsp_status_popup` first,
then push a plugin popup via `handle_plugin_command`. Assert the total
across both stacks is 1.
Issue 4 is the "if I click many times this popup sometimes stacks -
dismissing it I see the same popup underneath" report.
`handle_show_action_popup` uses `global_popups.show()` (plain) instead
of `show_or_replace()`, so repeating the same `popup_id` stacks
identical popups. Add `issue_4_repeated_plugin_action_popup_pushes_stack
_instead_of_replace` that pushes three popups with the same id and
asserts only one remains.
Both tests fail today, demonstrating the bugs. The 5 pre-existing
LSP-indicator-click bug tests still pass — these two are additions,
not edits.
Adds `pub fn Editor::global_popups()` as a read-only accessor for
tests; the field itself stays `pub(crate)`.
https://claude.ai/code/session_01EHPvWNSvRrhYffJtRTebB7
sinelaw
pushed a commit
that referenced
this pull request
May 26, 2026
…advanced features Tested: TC-060-065 (command palette full coverage), TC-070-073 (settings/theme/keybinding), TC-081-085 (binary file, empty file, rapid keys, resize, 12+ tabs), Git Log (55-commit live preview), Macro recording (F5/F4 workflow), Bookmarks (palette + Alt+N), Markdown preview (ANSI bold/italic rendering), Review Diff, Live Grep (77 results streaming), Diagnostics Panel, Smart Home, Position History (Alt+Left), Auto-close brackets, Surround selection, Duplicate Line, path:line:col palette syntax. 0 new bugs confirmed. Updated knowledge base with Settings UI workflow, keybinding editor details, macro/bookmark workflows, and binary file handling notes. Run #5 plan: Large file (100MB+), Theme Editor visual, multi-language syntax highlighting, code folding, git blame, whitespace indicators. https://claude.ai/code/session_01Rz2F6gaZfVSf95zNVemcdx
sinelaw
pushed a commit
that referenced
this pull request
May 27, 2026
A mouse click on a session row fires `select` with the clicked item's key (not the list key "sessions"), so the handler ignored it. Accept the click by also matching the payload's `list_key`, so clicking a row selects + live-switches it (and the focus event re-arms the dock). Add e2e: "/"+filter+Enter-returns-to-list (#5/#6), Space multi-select (#4), and mouse-click-row-then-Space-checks-that-row (#3). Make the order-stability test deterministic (sibling project dirs under one parent so the project-path sort is fixed) — the earlier flake was random tempdir paths, not the dock.
sinelaw
pushed a commit
that referenced
this pull request
May 27, 2026
A mouse click on a session row fires `select` with the clicked item's key (not the list key "sessions"), so the handler ignored it. Accept the click by also matching the payload's `list_key`, so clicking a row selects + live-switches it (and the focus event re-arms the dock). Add e2e: "/"+filter+Enter-returns-to-list (#5/#6), Space multi-select (#4), and mouse-click-row-then-Space-checks-that-row (#3). Make the order-stability test deterministic (sibling project dirs under one parent so the project-path sort is fixed) — the earlier flake was random tempdir paths, not the dock.
sinelaw
pushed a commit
that referenced
this pull request
May 31, 2026
A mouse click on a session row fires `select` with the clicked item's key (not the list key "sessions"), so the handler ignored it. Accept the click by also matching the payload's `list_key`, so clicking a row selects + live-switches it (and the focus event re-arms the dock). Add e2e: "/"+filter+Enter-returns-to-list (#5/#6), Space multi-select (#4), and mouse-click-row-then-Space-checks-that-row (#3). Make the order-stability test deterministic (sibling project dirs under one parent so the project-path sort is fixed) — the earlier flake was random tempdir paths, not the dock.
sinelaw
pushed a commit
that referenced
this pull request
Jun 3, 2026
…board
The async clipboard paste on master (anchor-based async read so a hung
X11/Wayland owner can't freeze the editor) made the capslock copy/paste
tests race: Ctrl+V kicks off an asynchronous system/OSC52 clipboard read
that never resolves in headless CI, so the assertion runs against the
un-pasted buffer. test_capslock_ctrl_v_pastes failed deterministically in
CI ("hello" vs "hellohello"); the cut/copy siblings are exposed to the
same flake.
Per CONTRIBUTING.md "Testing" #4, drive these through the internal-only
clipboard (set_clipboard_for_test enables internal_only mode) so the real
Ctrl+C/X/V keybinding flow is synchronous and isolated from the host —
the same pattern paste.rs / vi_mode.rs already use. The tests still
exercise the actual capslock+ctrl keybindings; only the clipboard backend
is swapped for the deterministic in-memory one.
sinelaw
pushed a commit
that referenced
this pull request
Jun 3, 2026
…board
The async clipboard paste on master (anchor-based async read so a hung
X11/Wayland owner can't freeze the editor) made the capslock copy/paste
tests race: Ctrl+V kicks off an asynchronous system/OSC52 clipboard read
that never resolves in headless CI, so the assertion runs against the
un-pasted buffer. test_capslock_ctrl_v_pastes failed deterministically in
CI ("hello" vs "hellohello"); the cut/copy siblings are exposed to the
same flake.
Per CONTRIBUTING.md "Testing" #4, drive these through the internal-only
clipboard (set_clipboard_for_test enables internal_only mode) so the real
Ctrl+C/X/V keybinding flow is synchronous and isolated from the host —
the same pattern paste.rs / vi_mode.rs already use. The tests still
exercise the actual capslock+ctrl keybindings; only the clipboard backend
is swapped for the deterministic in-memory one.
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
…ng infra After auditing what's actually in the codebase, the entire "non-modal banner system" line of design was over-engineering. The two reverts that precede this commit drop the BannerManager code. This commit brings the doc into alignment so the design story matches what we'll actually build. Audit findings, now reflected in the doc: - The status-bar click chain is wired and production-grade for every built-in indicator (LSP, warning, line-ending, encoding, language, message, remote): area tracking in `StatusBarLayout`, per-frame layout export through `WindowChrome`, click dispatch in `handle_click_status_bar`, hover styling. What's *missing* is per-token area tracking for plugin-registered status-bar tokens (`RegisterStatusBarElement`). That's a small extension to existing types, not new infrastructure. - The existing modal popup primitive is the right surface for our project-lifecycle questions, once we fix the *framing*. The trust modal already exists fully implemented at `show_workspace_trust_ popup` — it's just stubbed out at `popup_dialogs.rs:977`. Re- enabling it with a concrete body that names the actual `executable_content_markers` is a code change, not a primitive change. - Cross-plugin coordination via the existing `action_popup_result` broadcast scales fine at the current three-plugin scope. Standardizing the popup-id naming convention (`<plugin>:<question>`) costs nothing and gives the same ordering / invalidation guarantees a managed queue would. - The split between `trust.json` and per-plugin global state is not split-brain — it's different things in different places. No unification needed. Doc edits: - Principles: replace "Inline beats modal" (#4) with "Ask rarely, ask concretely" — and explain the retraction. What users hate about modal trust dialogs is abstract framing + bad timing, both fixable without dropping modality. - "What disappears from the user's life": replace "stacked popups, inline banners replace popups" with the actual mechanism — the existing `WorkspaceTrust` dedup short-circuit becomes the convention. Replace "(locked) pill" with "clickable chip that re-opens the prompt." - "Capabilities the editor needs": annotate each capability as extension-of-existing or genuinely-new. Add an explicit list of things we considered building and rejected (new banner primitive, managed popup queue, unified decision store), with the reasoning. - "Failure modes": "banner fatigue" becomes "popup fatigue," fixed by persistent dismissal + content-hash short-circuit. - "Why the rest of this doc exists": call out the banner-rejection decision explicitly so a future reader doesn't re-invent it. - "Goal of stepping-stone work": drop "modal popups not banners" as a difference (we're keeping modal popups in the end-state too). Keep the provenance gap and the status-bar-token clickability gap, rewrite the trust-modal gap as "re-enable with concrete framing." - "Path from here to the North Star": completely rewrite. Seven capabilities, ranked, with three explicit rejections of things I had previously been planning to build. Mirrors the audit findings. Anchor scenarios in §"What the user sees in the ideal world" now use `[Popup]` instead of `[Banner]`, reflecting that the surface is the existing popup primitive with better framing — not a new visual category. The user-visible end state is unchanged. https://claude.ai/code/session_019Gm3tj2kLNoQXCTp5Am9EH
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
…ng infra After auditing what's actually in the codebase, the entire "non-modal banner system" line of design was over-engineering. The two reverts that precede this commit drop the BannerManager code. This commit brings the doc into alignment so the design story matches what we'll actually build. Audit findings, now reflected in the doc: - The status-bar click chain is wired and production-grade for every built-in indicator (LSP, warning, line-ending, encoding, language, message, remote): area tracking in `StatusBarLayout`, per-frame layout export through `WindowChrome`, click dispatch in `handle_click_status_bar`, hover styling. What's *missing* is per-token area tracking for plugin-registered status-bar tokens (`RegisterStatusBarElement`). That's a small extension to existing types, not new infrastructure. - The existing modal popup primitive is the right surface for our project-lifecycle questions, once we fix the *framing*. The trust modal already exists fully implemented at `show_workspace_trust_ popup` — it's just stubbed out at `popup_dialogs.rs:977`. Re- enabling it with a concrete body that names the actual `executable_content_markers` is a code change, not a primitive change. - Cross-plugin coordination via the existing `action_popup_result` broadcast scales fine at the current three-plugin scope. Standardizing the popup-id naming convention (`<plugin>:<question>`) costs nothing and gives the same ordering / invalidation guarantees a managed queue would. - The split between `trust.json` and per-plugin global state is not split-brain — it's different things in different places. No unification needed. Doc edits: - Principles: replace "Inline beats modal" (#4) with "Ask rarely, ask concretely" — and explain the retraction. What users hate about modal trust dialogs is abstract framing + bad timing, both fixable without dropping modality. - "What disappears from the user's life": replace "stacked popups, inline banners replace popups" with the actual mechanism — the existing `WorkspaceTrust` dedup short-circuit becomes the convention. Replace "(locked) pill" with "clickable chip that re-opens the prompt." - "Capabilities the editor needs": annotate each capability as extension-of-existing or genuinely-new. Add an explicit list of things we considered building and rejected (new banner primitive, managed popup queue, unified decision store), with the reasoning. - "Failure modes": "banner fatigue" becomes "popup fatigue," fixed by persistent dismissal + content-hash short-circuit. - "Why the rest of this doc exists": call out the banner-rejection decision explicitly so a future reader doesn't re-invent it. - "Goal of stepping-stone work": drop "modal popups not banners" as a difference (we're keeping modal popups in the end-state too). Keep the provenance gap and the status-bar-token clickability gap, rewrite the trust-modal gap as "re-enable with concrete framing." - "Path from here to the North Star": completely rewrite. Seven capabilities, ranked, with three explicit rejections of things I had previously been planning to build. Mirrors the audit findings. Anchor scenarios in §"What the user sees in the ideal world" now use `[Popup]` instead of `[Banner]`, reflecting that the surface is the existing popup primitive with better framing — not a new visual category. The user-visible end state is unchanged. https://claude.ai/code/session_019Gm3tj2kLNoQXCTp5Am9EH
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
) - cargo fmt for the alignment/ops changes (fmt CI was red). - Focusing the FILES panel now resets its cursor to the selected row's start, so it no longer scrolls horizontally to a long path's end-of-line. https://claude.ai/code/session_01D1vLAnwKHqmebN9qRQ9E47
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
…shift-wheel h-scroll - #2: opening a comment from the panel in side-by-side now rebuilds the composite focused on the comment's hunk (parameterized buildCenterComposite with a focus-hunk index) instead of staying at the first hunk — the unified cursor jump is inert when the composite is showing. - #3: comments rail is narrow by default (~15% width; diff/comments split 0.74 -> 0.82). - #4: Shift+mouse-wheel over the side-by-side area now pans horizontally — handle_horizontal_scroll scrolls the composite's per-pane left_column (it only touched the split viewport, which the composite render ignores). - #1: pin the FILES cursor to the selected row's start on every focus path (incl. mouse via buffer_activated), so it can't land horizontally scrolled. https://claude.ai/code/session_01D1vLAnwKHqmebN9qRQ9E47
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
…h-scroll (#4) - test_review_comments_rail_is_narrow: the COMMENTS header starts past column 130 of a 160-col screen (rail ~15%). - test_review_side_by_side_shift_wheel_scrolls_horizontally: Shift+wheel on the composite pans it (rendered content changes from the left-edge state). (#2 comment-jump and #1 file-focus h-scroll are verified manually in tmux; the harness can't drive the async comment-jump rebuild / the residual #1 edge reliably.) https://claude.ai/code/session_01D1vLAnwKHqmebN9qRQ9E47
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
) - cargo fmt for the alignment/ops changes (fmt CI was red). - Focusing the FILES panel now resets its cursor to the selected row's start, so it no longer scrolls horizontally to a long path's end-of-line. https://claude.ai/code/session_01D1vLAnwKHqmebN9qRQ9E47
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
…shift-wheel h-scroll - #2: opening a comment from the panel in side-by-side now rebuilds the composite focused on the comment's hunk (parameterized buildCenterComposite with a focus-hunk index) instead of staying at the first hunk — the unified cursor jump is inert when the composite is showing. - #3: comments rail is narrow by default (~15% width; diff/comments split 0.74 -> 0.82). - #4: Shift+mouse-wheel over the side-by-side area now pans horizontally — handle_horizontal_scroll scrolls the composite's per-pane left_column (it only touched the split viewport, which the composite render ignores). - #1: pin the FILES cursor to the selected row's start on every focus path (incl. mouse via buffer_activated), so it can't land horizontally scrolled. https://claude.ai/code/session_01D1vLAnwKHqmebN9qRQ9E47
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
…h-scroll (#4) - test_review_comments_rail_is_narrow: the COMMENTS header starts past column 130 of a 160-col screen (rail ~15%). - test_review_side_by_side_shift_wheel_scrolls_horizontally: Shift+wheel on the composite pans it (rendered content changes from the left-edge state). (#2 comment-jump and #1 file-focus h-scroll are verified manually in tmux; the harness can't drive the async comment-jump rebuild / the residual #1 edge reliably.) https://claude.ai/code/session_01D1vLAnwKHqmebN9qRQ9E47
sinelaw
pushed a commit
that referenced
this pull request
Jun 8, 2026
…ng infra After auditing what's actually in the codebase, the entire "non-modal banner system" line of design was over-engineering. The two reverts that precede this commit drop the BannerManager code. This commit brings the doc into alignment so the design story matches what we'll actually build. Audit findings, now reflected in the doc: - The status-bar click chain is wired and production-grade for every built-in indicator (LSP, warning, line-ending, encoding, language, message, remote): area tracking in `StatusBarLayout`, per-frame layout export through `WindowChrome`, click dispatch in `handle_click_status_bar`, hover styling. What's *missing* is per-token area tracking for plugin-registered status-bar tokens (`RegisterStatusBarElement`). That's a small extension to existing types, not new infrastructure. - The existing modal popup primitive is the right surface for our project-lifecycle questions, once we fix the *framing*. The trust modal already exists fully implemented at `show_workspace_trust_ popup` — it's just stubbed out at `popup_dialogs.rs:977`. Re- enabling it with a concrete body that names the actual `executable_content_markers` is a code change, not a primitive change. - Cross-plugin coordination via the existing `action_popup_result` broadcast scales fine at the current three-plugin scope. Standardizing the popup-id naming convention (`<plugin>:<question>`) costs nothing and gives the same ordering / invalidation guarantees a managed queue would. - The split between `trust.json` and per-plugin global state is not split-brain — it's different things in different places. No unification needed. Doc edits: - Principles: replace "Inline beats modal" (#4) with "Ask rarely, ask concretely" — and explain the retraction. What users hate about modal trust dialogs is abstract framing + bad timing, both fixable without dropping modality. - "What disappears from the user's life": replace "stacked popups, inline banners replace popups" with the actual mechanism — the existing `WorkspaceTrust` dedup short-circuit becomes the convention. Replace "(locked) pill" with "clickable chip that re-opens the prompt." - "Capabilities the editor needs": annotate each capability as extension-of-existing or genuinely-new. Add an explicit list of things we considered building and rejected (new banner primitive, managed popup queue, unified decision store), with the reasoning. - "Failure modes": "banner fatigue" becomes "popup fatigue," fixed by persistent dismissal + content-hash short-circuit. - "Why the rest of this doc exists": call out the banner-rejection decision explicitly so a future reader doesn't re-invent it. - "Goal of stepping-stone work": drop "modal popups not banners" as a difference (we're keeping modal popups in the end-state too). Keep the provenance gap and the status-bar-token clickability gap, rewrite the trust-modal gap as "re-enable with concrete framing." - "Path from here to the North Star": completely rewrite. Seven capabilities, ranked, with three explicit rejections of things I had previously been planning to build. Mirrors the audit findings. Anchor scenarios in §"What the user sees in the ideal world" now use `[Popup]` instead of `[Banner]`, reflecting that the surface is the existing popup primitive with better framing — not a new visual category. The user-visible end state is unchanged. https://claude.ai/code/session_019Gm3tj2kLNoQXCTp5Am9EH
This was referenced Jun 30, 2026
sinelaw
pushed a commit
that referenced
this pull request
Jul 20, 2026
…ead of removing them CI's Playwright suite caught that removing the mutating POST routes broke the web-UI E2E tests: the harness drives the editor through `POST /action` (15+ call sites), `/widget`, and `/reset` — the latter has no WebSocket equivalent. My earlier "nothing uses them" investigation was wrong (it searched for `fetch` / uppercase `POST` and missed Playwright's `page.request.post`). Restore the routes and instead close the CSRF/finding-#3 hole the intended way: apply the SAME same-origin/Host check as the `/ws` upgrade to every state-mutating POST (in `serve_request`). A cross-origin browser page sends its own `Origin` and is rejected; non-browser callers (curl, the Playwright request API, the parity harness) send no `Origin` and pass, so the routes stay scriptable. This keeps the Content-Length crash fix (#1), the write-timeout (#2), the rebinding guard (#4), and the rest intact. Verified: the full Playwright suite passes locally (149/0), including the trust-dialog and live-grep-toolbar sections that failed in CI; webui unit tests and scene_parity pass. Docs updated to describe the gating (not removal). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LsqkqerfYQ4A48asmUxDQG
sinelaw
pushed a commit
that referenced
this pull request
Jul 20, 2026
…ead of removing them CI's Playwright suite caught that removing the mutating POST routes broke the web-UI E2E tests: the harness drives the editor through `POST /action` (15+ call sites), `/widget`, and `/reset` — the latter has no WebSocket equivalent. My earlier "nothing uses them" investigation was wrong (it searched for `fetch` / uppercase `POST` and missed Playwright's `page.request.post`). Restore the routes and instead close the CSRF/finding-#3 hole the intended way: apply the SAME same-origin/Host check as the `/ws` upgrade to every state-mutating POST (in `serve_request`). A cross-origin browser page sends its own `Origin` and is rejected; non-browser callers (curl, the Playwright request API, the parity harness) send no `Origin` and pass, so the routes stay scriptable. This keeps the Content-Length crash fix (#1), the write-timeout (#2), the rebinding guard (#4), and the rest intact. Verified: the full Playwright suite passes locally (149/0), including the trust-dialog and live-grep-toolbar sections that failed in CI; webui unit tests and scene_parity pass. Docs updated to describe the gating (not removal). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LsqkqerfYQ4A48asmUxDQG
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.
Updates the requirements on tree-sitter-highlight to permit the latest version.
Release notes
Sourced from tree-sitter-highlight's releases.
Commits
2a835ee0.25.33ad1c7dFix cases where error recovery could infinite loop (#4257) (#4262)b1a7074fix(generate): markTSCharacterRangeasstatic(#4255)6f2dbaabuild: do not define _POSIX_C_SOURCE on NetBSD (#4196)781dc05ci: separate nightly lints to separate job1f64036fix(test): update expected tree-sitter-rust supertypes4eb46b4fix(rust): adapt to some new nightly lintsd73126dfix(web): provide type in the exports637a3e1fix(wasm): restore passing in ERROR todescendantsOfType(#4226)8b5c63btree-sitter-language 0.1.5Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)