I'm developing a package that wants to prompt the user to add some code to their .R profile (in this case, a .Last function.)
I love how use_usethis() locates and opens the .Rprofile via edit_r_profile while also displaying the code to be added and writing it to the clipboard. However, the function code_block() for formatting and accessing the clipboard is not exported currently. Are there plans to export code_block() in the future so we can create generic use_usethis-esque functions? Or perhaps create some kind of API for creating generic use_ functions, maybe by way of a closure/function factory?
use_ <- function(edit_function, todo_text, code, ...) {
function() {
edit_function(...)
todo(todo_text)
code_block(code)
}
}
use_x <- use_(edit_r_profile,
todo_text = "Include this code in your .Rprofile to get x package working",
code = c(".Last <- function() {", "message('All done.')", "}")
(Unless there is some way to call use_template() for this that I've missed?)
We definitely want usethis to be extensible! Hence the recent export of use_template() as you point out.
I don't have a short, immediate answer, but am happy to think and discuss how to facilitate this more generally.
cc @hadley
I think we can consider this family of functions for export in the next release. We'll need to rethink their names and possibly consider a common prefix.
@jennybc any thoughts on what prefix we should use? We currently have done(), todo(), code_block() (which I suspect will be reduced to _code()). Random ideas: info_, show_, user_, cat_
What do you think of ui_?
Just a suggestion; these functions feel to me like they'd fit in nicely with cat_line() and friends from r-lib/cli/cat.R
@gadenbuie that is too general; we need something specific for this package.
@jennybc ui isn't a verb, but otherwise I don't mind it.
@hadley understood re: naming. Just to clarify, I'm suggesting moving the cli "UI" functions to r-lib/cli and having usethis depend on cli. If the cli ui functions are exported from usethis, package authors will end up importing usethis to use done(), todo(), etc., and I wonder if this aligns with the goals of usethis. This is only partially the use case requested in this issue, but is the motivation behind #456.
@gadenbuie I think that is a bad idea because we want to tailor these functions specifically for the needs of usethis, not for general usage.
So this would give us:
ui_done(), ui_todo(), ui_code_block() ui_field(), ui_value(), ui_code()ui_yep(), ui_nope()How does that sound, en masse?
And maybe ui_stop() and ui_warn() to replace stop_glue() and warning_glue()