Skip to content

Collapse the unrelated methods when focusing on a state error, listed on hover - #171

Merged
CatarinaGamboa merged 2 commits into
mainfrom
feat/focus-collapse
Oct 28, 2026
Merged

CatarinaGamboa merged 2 commits into
mainfrom
feat/focus-collapse

Conversation

@CatarinaGamboa

@CatarinaGamboa CatarinaGamboa commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

Part of #170.

Why

Focus mode dimmed the methods unrelated to a state error but kept their text, so the layout did not move (#158). On a large machine the dimmed label stacks still took the space. In the UDP chat client the state the error is about, closed, was below the fold.

What

In focus mode:

  • Collapse. The dimmed methods of each label become a count: receive + +9 more, or 2 methods. Overloads count once. A single dimmed method keeps its name and conditions.
  • List on hover. Hovering a count lists its methods, with their conditions, next to the label. A click keeps the list open until the next click, a pan or a zoom. The diagram is not laid out again, so the list appears at once. The list goes right, left, above or below the label, or beside the diagram at the label's height: wherever it covers the fewest states, labels and transition lines, and the closest such place on a tie.
  • Constructors. The constructors of each state are merged into one arrow, e.g. 4 constructors.
  • Layout. The diagram is laid out again. A tall diagram is shrunk to fit the panel, but never below 60%.
  • Bright. Only the failed method stays bright.
  • States. No state is removed.

Show all is unchanged.

An earlier version of this PR also drew a dashed "way to an expected state": a shortest path along the diagram's transitions. It was dropped. The path ignores the transitions' conditions and the code, and for a state that no call leaves (closed) it could only suggest creating a new object. The ways to fix now come from the verifier's hints only (#172).

Error categories (liquid-java/liquidjava#418) are not used to choose what to show. #170 explains why.

Screenshots

Real verifier output (0.0.36) in headless VS Code.

UDP chat client (E_OSS_A1_22): receive after an if that may close the socket. In the screenshots, the three from = "closed(this) && connected(old(this))" preconditions are removed from the DatagramSocket spec. With them, verifier 0.0.36 sends no state context or hints for this error, and the view can only say "Invalid method call at line 28". That is a verifier issue, separate from this PR.

Before After

On hover, placed off the states and transitions: +12 more next to bound goes beside the diagram, +16 more next to connected to its right, and the 2 methods of ImageWriteParam left of tilingExplicit and right of setTiling.

UDP, bound UDP, connected
ImageWriteParam, bottom ImageWriteParam, middle

ImageWriteParam: setTiling from startTiling.

Before After
Show all (unchanged)

The collapsed "Ways to fix" section in the screenshots comes from the stacked PR.

Tests

  • npm run test:unit: 123 passed. New tests cover collapsing, the list on hover, pinning it with a click and closing it on a click, pan or zoom, placing it off the states, labels and lines and inside the panel, merging constructors and the entry transitions from Draw entry transitions on the state machine #169, the fit to the panel, and Show all being unchanged.
  • tsc -p tsconfig.test.json and npm run lint: clean.
  • npm test (VS Code): 9 + 1 passing, and server mvn test: 35 passing, both run on the stacked branch, which includes this one.

Rebased on #169. In focus mode, entry transitions are dimmed and merged per state, the same way constructors are.

🤖 Generated with Claude Code

…k the ways to fix it

Focus mode dimmed the methods unrelated to a state error but kept their
text, so the layout did not move. On a large machine like DatagramSocket
the dimmed label stacks still took the space, and the state the error is
about was below the fold.

Focus mode now collapses the dimmed methods of each label into a count
named in its tooltip ("+9 more", "2 methods"), merges the constructors
of each state, and lays the diagram out again. A tall focused diagram is
shrunk to fit the panel, but never below 60%. Show all is unchanged.

Only the failed method and the ways to fix the error stay bright: a
shortest path along the diagram's transitions from each state that
rejects the call to a state that accepts it, drawn dashed in the colour
of the expected states. When no transition leads there, the constructors
of the expected states are the way, as the verifier's hint says.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@CatarinaGamboa CatarinaGamboa changed the title Collapse the unrelated methods when focusing on a state error and mark the ways to fix it Collapse the unrelated methods when focusing on a state error, expandable on click Oct 27, 2026
@CatarinaGamboa CatarinaGamboa changed the title Collapse the unrelated methods when focusing on a state error, expandable on click Collapse the unrelated methods when focusing on a state error, listed on hover Oct 27, 2026
The shortest way along the diagram ignored the transitions' conditions and the
code, and fell back to "create a new object" for a dead-end state. Only the
failed method stays bright now; the verifier's hints are the ways to fix.

Hovering "+N more" or "N methods" lists the methods, with their conditions,
next to the label, and a click keeps the list until the next click, a pan, or a
zoom. The diagram is not laid out again, so the list shows at once. The list
goes right, left, above, or below the label, or beside the diagram, wherever it
covers the fewest states, labels, and transition lines.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@CatarinaGamboa
CatarinaGamboa merged commit 80bed18 into main Oct 28, 2026
3 checks passed
CatarinaGamboa added a commit that referenced this pull request Nov 11, 2026
…rong (#182)

Closes #180. Based on main (#178 and #174 are merged there); not stacked
on #172 (see below).

## What changes, per proposal

When a call needs the states of several state sets (Door: `d.lock();
d.open();`, `open` needs `doorState(this) == closed && lockState(this)
== unlocked`):

- **Failure marked where it is.** Which set is wrong comes from the
server's `errorContext` per diagram, not from message text: a set whose
`invalidStates` is not empty is in a wrong state; a set whose possible
states are all accepted, with another set in a wrong state, is "right".
In a right set, a transition of the call from the actual state whose
condition names the wrong set is drawn as usual (white, normal arrow)
and only the clause the actual state does not meet is red, also when
conditions are collapsed. In the wrong set the call is red as before.
Every other transition of the call stays red as now: when it has no
condition on the wrong set, when the condition is not only states, when
no set is wrong on its own (the verifier can only reject the
combination), or when the state is unknown.
- **Wrong set first.** `orderStateMachines` puts the sets in a wrong
state first, then the other sets of the error, then the rest. Focus mode
fits the first diagram as before, so the ✕ state is now on screen
(A1_38: `mark` first, the case from the IDE review).
- **Self-loops.** A transition that keeps its state is drawn as a round
loop (same ends, same side, as far out as before so it stays inside the
laid-out SVG, slightly thicker) instead of ELK's flat curl the size of
its arrowhead. It is redrawn after Mermaid renders, from a `%%
lj-self-loops:` comment like the existing dimmed-transitions one.
- **Conditions as in the spec, before and after the method.** A label
reads `[condition before] method [condition after]` on one line, e.g.
`[lockState(this) == unlocked] open`. Each condition is the spec text,
so it reads like the Expected box and the spec, and a condition with
other clauses stays readable: in `[lockState(this) == unlocked &&
size(this) > 0] open` only the clause the actual state does not meet is
red. Edge labels no longer wrap at Mermaid's 200px width, so a condition
stays on the line of its method.
- **Set names in the summary.** "expected doorState `closed`, lockState
`unlocked` · actual lockState `locked`": expected in declaration order;
actual lists only the sets in a wrong state (all known ones if none is).
A set in which every state allows the call is left out of both sides,
for named and unnamed sets (the A1_56 "(undoable or notUndoable) and
redoable" case). Unnamed sets keep the current wording.

Single-set classes are unchanged except for the round self-loops and the
summary naming a named set (`expected phase open · actual phase
closed`).

## Ways to fix and #172

Not in this PR. Highlighting `unlock` on the diagram needs to know which
calls a hint suggests, and `HintDTO` only has `kind` and `message`;
getting the calls from the message text, or from paths in the diagram
(judged unsound in #171), are both out. #172 lists the verifier's hints
in a "Ways to fix" section and does not draw them; drawing a hint is
#156, which needs a structured hint from the verifier first. So this PR
does not depend on #172 and does not touch the hints; the two only meet
in `fsm.ts`/`script.ts` call sites and should rebase cleanly in either
order.

## Screenshots

Headless VS Code, this branch's server (verifier 0.0.37, fsm 0.2.3).
Focus mode is what opens from the error.

**Door** (the spec from #178, `d.lock(); d.open();`):

| | Before (main) | After |
|---|---|---|
| Focus on error | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/door-focus-before.png"
width="380"> | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/door-focus-after.png"
width="380"> |
| Show all | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/door-all-before.png"
width="380"> | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/door-all-after.png"
width="380"> |

**Study exercise A1_38** (BufferedInputStream, sets `stream` and `mark`;
`buffered.reset()` without `mark()`; proposal-D-task-types with
liquidjava-api 0.0.8):

| | Before (main) | After |
|---|---|---|
| Focus on error | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/a138-focus-before.png"
width="380"> | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/a138-focus-after.png"
width="380"> |
| Show all | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/a138-all-before.png"
width="380"> | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/a138-all-after.png"
width="380"> |

The right set, scrolled down in focus mode (call drawn as usual, unmet
condition red). These two and the A1_38 shots are from before the change
to conditions as in the spec, which they still show as `[lockState:
unlocked]`; the Door shots above are current:

| Door `doorState` | A1_38 `stream` |
|---|---|
| <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/door-focus-second-after.png"
width="380"> | <img
src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/180/a138-focus-second-after.png"
width="380"> |

## Not in this PR

- Marking states that are current and fine (`closed` in `doorState`,
`open` in `stream`), as agreed.
- Highlighting the ways to fix on the diagram (above).

## Reviews

- Codex: 5 rounds (comments below); rounds 1-4 found one or two issues
each, all fixed; round 5 found nothing.
- Clean-code audit: comment below; one fix, the rest declined with
reasons.

## Tests

- client: `npm run test:unit` 128 passed (5 new, each fails without the
change: order, call/condition marks with `!=` and collapsed conditions,
round loop, named summary without the any-state set; one existing
expectation gains the self-loop comment), `npm run test:typecheck` and
`npm run lint` clean.
- server: no change; `mvn -B test` 39 passed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant