Top-level (NSE) support for weights and labels#639
Merged
Conversation
Closed
Owner
Author
|
@zeileis @vincentarelbundock Not to nag or rush, but please let know if you have any conceptual objection to me merging this (or would like to test / kick the tyres before giving the go-ahead). |
Collaborator
Owner
Author
Oh, that's a cool example. I'll add it to the documentation. |
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.

Closes #332
Adds two new, top-level
tinyplot()arguments:weightsarg only passes through for the model-fit types (e.g.,"lm","glm") and distribution types (e.g.,"histogram","spineplot"). Passing through a top-levelweightsarg for a non-supported type is ignored, but triggers a warning (since it implies an unused statistical transformation).labelsarg only passes through fortype_textand is silently ignored otherwise.Both of these are supported via NSE from the top-level, but users can also supply an equivalent atomic vector argument directly through the relevant
type_*()constructor. For example, these two lines are equivalent:(However, the bottom variant is safer b/c it is incorporated into the
model.framecomputation, and so will correctly account forNAs across input columns, as well assubsetoperations.)If both forms are provided at the same time, then the top-level variant wins out.
MWE
Created on 2026-06-20 with reprex v2.1.1