You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So a package could register a theme, and then this would be used when printing errors from that package, using topenv().
This is still not ideal, though. E.g. if I define custom formatting for a (say) processx::process object, then that should be used, always, when formatting such an object.
Maybe cli_format() or rather a similar function could return a style instead of the formatted string, and then this style would be applied for .val? And the function would be S3, so it would be always used.
So these are actually two different features.
The text was updated successfully, but these errors were encountered:
If I can chip in on your first statement, if I understand you correctly. I think it would lead to a nightmare if each package can implement their own formatting theme for their error and warnings. Not only would it be difficult for beginners and users with visual impairments to struggle with various ways of communicating the same thing, but also for regular users who prefer consistency. But beyond errors and warnings, I would not have nightmares. :) (P.S. Among my top-5 favourite packages)
So a package could register a theme, and then this would be used when printing errors from that package, using
topenv()
.This is still not ideal, though. E.g. if I define custom formatting for a (say)
processx::process
object, then that should be used, always, when formatting such an object.Maybe
cli_format()
or rather a similar function could return a style instead of the formatted string, and then this style would be applied for.val
? And the function would be S3, so it would be always used.So these are actually two different features.
The text was updated successfully, but these errors were encountered: