Document what merging a row of repeated header labels looks like (#120) - #122
Merged
Conversation
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>
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
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.
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
mergedocs 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 singleBaselinespanning all six: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
mergedefault fromTRUEto"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.
DESCRIPTIONis deliberately untouched; the local roxygen2 is 8.0.0 against the repo's pinned 7.3.2, anddocument()wants to rewriteRoxygenNoteintoConfig/roxygen2/version. That bump is not this PR's business, so it was reverted — the regenerated.Rdcarries only the prose change.🤖 Generated with Claude Code