Repository navigation
e-stepper: arrows to frames only on hover; to objects on hover unless "From program" is on - #174
Conversation
…hover unless "From program" is on Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 8d3e768 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
…othing deployed (#175) Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Agreed with @sayomaki (SA@NUS feedback):
Protocol:
onAnchors(resolve, fromProgram?)gets a second argument. A host that omits it behaves as before (it only calledonAnchorswith a resolver while "From program" was on, and withnullotherwise). The frontend needs a matching change to keep the anchors while "From program" is off and passfromProgram=false; until then, with the filter off there are no arrows at all, as today.Tests: vitest (e-stepper 83, all 315).
tscshows an error atProgramArrows.tsx(scaleonCseDiagramPoint) that is already onmain.🤖 Generated with Claude Code