Skip to content

Document what merging a row of repeated header labels looks like (#120) - #122

Merged
mstackhouse merged 1 commit into
developmentfrom
gh_issue_120
Jul 27, 2026
Merged

Document what merging a row of repeated header labels looks like (#120)#122
mstackhouse merged 1 commit into
developmentfrom
gh_issue_120

Conversation

@mstackhouse

Copy link
Copy Markdown
Member

The only clinify change to come out of #120. The investigation is written up in full on the issue; the short version is that 7 of the 9 reported tables were a harness bug and the other 2 were pilot code, so there is no rendering fix to make here.

What there is: the merge docs explained the mechanism — identical, adjacent header cells are merged — but never the symptom. Merged, the run renders as one label centred over all of it, so the repeats are no longer there to read.

That matters most for the bottom header row, which holds each column's own label. In the case that prompted this, six columns each labelled "Baseline" came out as a single Baseline spanning all six:

ref   Week@267 Shift@303 to@326 Baseline@352 Baseline@413 Baseline@473 Baseline@534 Baseline@594 Baseline@655
cand  Week@269 to@314 Baseline@499

Five labels gone from the output, with nothing to say so. merge = "spanners" is the answer and was already there — only the description of what it saves you from was missing.

Considered and rejected

Changing the merge default from TRUE to "spanners". There is a real argument for it: the bottom row holds each column's own label, so merging it hides labels rather than forming a spanner, which is exactly where merging is most likely to be unintended, and it produced the worst symptom of anything found in #120.

Against: it is a breaking default change on a CRAN package that would silently alter existing users' output and every snapshot test, to fix something with a documented one-word opt-out that the very suite that hit this already uses on a neighbouring table. Not worth the cost. Recording it here in case it belongs in a future major version.

Verification

Documentation only — no code paths touched. Full suite run anyway: 2,176 tests pass, no snapshot changes. DESCRIPTION is deliberately untouched; the local roxygen2 is 8.0.0 against the repo's pinned 7.3.2, and document() wants to rewrite RoxygenNote into Config/roxygen2/version. That bump is not this PR's business, so it was reverted — the regenerated .Rd carries only the prose change.

🤖 Generated with Claude Code

The `merge` docs explained the mechanism - identical, adjacent header
cells are merged - but never the symptom, which is that the run then
renders as one label centred over all of it. The repeats are not there
to read any more.

That matters most for the bottom header row, which holds each column's
own label. Six columns each labelled "Baseline" come out as a single
Baseline spanning all six, so five labels are simply gone from the
output with nothing to say so. `merge = "spanners"` is the answer and
was already there; only the description of what it saves you from was
missing.

Found while investigating #120, where this had been misreported as a
header wrapping difference.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@mstackhouse
mstackhouse merged commit 1aee2d1 into development Jul 27, 2026
4 checks passed
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