Why is KNITR_WIDTH a global option and not a package option?

[krlmlr]

I have found KNITR_WIDTH through code inspection, after I have noticed that knitr resets option(width=75). Very useful indeed.

I am willing to contribute documentation, but then I'm unsure where to put it. Perhaps in options.md? But then a new section, "Global options" would have to be introduced.

This leads to the question: Why is KNITR_WIDTH a global option in the first place? Wouldn't it be more consistent to use a package option here? Besides KNITR_WIDTH, only config.pandoc seems to be queried using the getOption call.

[yihui]

Because opts_knit requires knitr to be loaded, whereas options() can be used anywhere (e.g. in ~/.Rprofile) since it is a base R function. I kind of regret the invention of opts_knit now. Perhaps I should have used options(knitr.foo) to set the package option foo from day one; although now all the package options can be read from options() in that way.

KNITR_WIDTH might be a bad name as well... perhaps it should be knitr.width

I have not documented it because I have not made the decision yet.

[krlmlr]

A transition to global options instead of opts_knit still should be possible, by forwarding the calls to opts_knit to the global options interface. May I suggest maintaining a distinction between chunk and package option using a different prefix, say, knitr.chunk. vs. knitr.?

I haven't found a corresponding issue in the issue tracker. Also, we should not forget documenting knitr.width once the transition is done.

[yihui]

I do not plan to do that to opts_chunk. Now KNITR_WIDTH has been renamed to knitr.width, and documented.

[yihui]

On second thought, I think it makes sense to be able to set chunk options via something like options(knitr.chunk.foo) for opts_chunk$set(foo), but then I will have to break what I did before again, because for package options, I cannot use options(knitr.foo). I need to change the convention to options(knitr.package.foo). I wonder if there will be many users yelling at me for this change...

[krlmlr]

The breaking change shouldn't be necessary unless you have a package option that starts with chunk.. ?

[yihui]

That is right, and I do not have a package option starting with chunk., but for the sake of a more consistent naming convention, knitr.chunk.foo and knitr.package.foo are more favorable.

[krlmlr]

I think knitr.chunk and knitr.package are too long for a prefix anyway. Why not use knitr and knitrc prefixes? No compatibility hassles + (more or less) clean naming convention.

[yihui]

The main purpose of this is to allow users to change the default package options and chunk options in ~/.Rprofile, which only needs to be done once. Most users probably do not need to do this at all. So I do not think a long prefix is a big concern.

[yihui]

I'll keep backward compatibility for a while so users can move from options(knitr.foo) to options(knitr.package.foo)

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.