fix: land the authored-source and edge-label work that merged into the wrong branch - #48
Merged
Merged
Conversation
`cal:referencedUri` answers two questions at once — drill into this element, and show me its source — and that works only for as long as both have the same answer. For a diagram generated from something else they come apart. Drilling has to stay inside the generated file, because that is where the definitions being drilled into live; "show me the source" wants the file a person actually typed. One slot means picking which of the two features to break, and the consumer that hit this picked drill-down and lost source navigation entirely. So a producer that knows both files can now say both: `meta.authoredSource` becomes its own pair of keys and its own context-menu item, and the existing two targets are untouched. Nothing here names a language or a toolchain. Any product with a compile step between what someone wrote and what the diagram is built from has this shape; the platform only learns that such a step can exist. Two deliberate refusals in the implementation. The authored target does NOT fall back to the diagram's own file the way the other two do — there, a missing range still means "somewhere in this document", whereas an absent authored file means the producer made no such claim, and offering the generated file under that label would misrepresent which file the reader is being sent to. And both a file and a line are required, because a half-populated locator navigates to the top of a file nobody asked for, which is worse than not offering the item. For every existing product this is inert: no `authoredSource`, no keys, no third menu item, and 850 tests plus all four neutrality gates pass unchanged.
A dataflow diagram's edges are not interchangeable. One may carry a 32-bit value and the next a single bit; one may be a token-carrying channel and its neighbour a plain signal. Drawn identically, the only way to tell them apart is to click each one and read the property panel — which is fine for checking a suspicion and useless for forming one. `meta.label` is text the producer formatted, `meta.width` a bit count, and they describe the same thing at different resolutions. Both reach the model, because both are true and a property panel may want either; the view draws exactly one, preferring the label. Two captions on one line would add no information. Formatted by the producer and shown verbatim, for the same reason a port's type is: the platform re-deriving it from anything structural would drift from how the language actually writes it, and differ between products. Drawn above the line, and higher again when a badge is already there, since the queue depth and the open button occupy the midpoint and a caption landing on one makes both unreadable. The halo is `paint-order` rather than a filled pill: every edge that states a width gets one of these, so a pill would end up weighing as much as the edges do, whereas a halo costs nothing over empty space and only shows up where the text would otherwise be illegible against a line or a box. Inert for a producer that states neither.
feat: a third navigation target, for a diagram whose file nobody wrote
feat: write on a connection what it carries
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.
Recovers #38 and #40, whose content never reached
main.What happened
Both were based on
feat/producer-declared-render-hooks(#37's branch), not onmain. I merged #37 intomainfirst and then merged #38 and #40 without re-checking their base — so they merged into that branch instead. GitHub reported both as merged, because they were: into the wrong target.Nothing was lost — both merge commits sit on that branch, which is where this comes from.
mainsimply never received them, and neither did the built bundles.How it was caught
Not by the merges, which reported success, and not by the test suite, which stayed green because the tests went missing along with the code. It showed up when I grepped the rebuilt bundles for each merged feature and two of them came back zero:
Which is the argument for checking the artifact rather than the merge result.
Contents
AUTHORED_URI/AUTHORED_SOURCE_RANGE: a third navigation target, for a diagram whose file nobody wrote.EDGE_LABELorEDGE_WIDTH.Both re-verified against current
mainrather than against the base they were written on: typecheck 5/5, neutrality 5/5, full suite 928 tests green.