On Tue, Jan 7, 2020 at 6:14 AM brodie gaslam via R-devel
<r-devel@r-project.org> wrote:
>
> For whatever my 2c are worth I think this would be nice. I'm still
> uncomfortable at having to call `options` in my package `diffobj` to set
> output width.
Adding a few more cents: It might be worth considering "who" should be
allow to control the 'width' argument. In an interactive session,
it's neat for the user to quickly be able to adjust 'width'. But in
what cases should this be controlled by a (package) developer? What
assumptions can the developer safely make about the 'width' of the end
user? I don't know the answer to this and I'm sure one can find valid
cases where it makes sense to set the 'width' in a package - maybe
like width = 0.90 * getOption("width", 80)?
Could it be that print() ignoring 'width' has protected us from
packages producing output with a fixed, hardcoded width that is set by
the developer? If print() us updated to acknowledge 'width', will we
start seeing print(..., width = 120) and so on in package code? Is
this good or bad? This might be a complementary problem to what we
have with 'stringsAsFactors' where the user's settings can override
the intention of the developer.
/Henrik
>
> And since the topic is here, what about `show`? Feels like it should accept
> `...` so that it too could be given some set of standard or non standard
> parameters, including `width`.
> Happy new decade.
> B.
>
> On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler
> <maech...@stat.math.ethz.ch> wrote:
>
> One of the things I often wish R would work with:
>
> When calling print() explicitly --- as I do not so rarely, e.g.,
> specifying digits = <nd> ---
> it sometimes seems awkward that from the printing options() ,
> one can specify 'digits' and it has default digits = NULL which is
> documented to be equivalent to digits = getOption("digits"),
> but one cannot specify 'width'
> ... well "even worse": one *can* specify 'width = .' but it is
> silently ignored - as well documented on ?print.default
>
> Before considering to add this for R 4.0.0, doing the work
> myself, I'd quickly wanted to hear opinions / caveats / .. about this.
>
> wishing you all a Happy New Year,
> Martin
>
> Martin Maechler
> ETH Zurich and R Core Team
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
