Should we support a "fill" argument as an alias for "bg"?

[grantmcdermott]

My sense is that bg is not well known among non-dedicated base plot users.

From a practical perspective, I often find myself mistyping by = "by" (instead of bg = "by") by mistake :-/

Having the fill = "by" fallback is something I'm likely to mistype less often.

[vincentarelbundock]

My 2 cents (weakly held):

I get what you're saying, but thought that the package's design goal was to stick as close as possible to base. In general, I'm not a big fan of aliases, so if there's already an argument, I'd lean on document and vignettes instead of inventing a new non-Base name.

[zeileis]

I'm not sure. I can see both of your arguments. I'll add a couple of comments which are probably not overly helpful...

• The fill is also a noticeable example where gpar() in grid deviates from classic base graphics.
• More than once I've also been confused when using polygon() where the fill color is set by col and not fill.
• However, my main concern would be that at some point we may need fill for something else.
• So I would probably be risk adverse and stick to bg. But, if implemented, I would probably find fill handy to use.

[grantmcdermott]

Thanks both. Definitely appreciate the feedback. I'm finding it hard to let this one slide. I'll mull it over this weekend some more and keep open for now.

[grantmcdermott]

Okay, after thinking it over for a few days I'm still quite motivated to add fill as an alias for bg.

(Sorry @vincentarelbundock. But at least you said your views were weakly held so hopefully this won't be too annoying!)

In my view, doing so would still allow the package to be consistent with base plot, since the bg behaviour would be preserved regardless. @zeileis brings up a good point of comparison vis-a-vis grid and I honestly can't think of any other functionality that I'd want to role into a "fill" argument otherwise. (Although, at some point we may consider supporting "density" and "angle" arguments to handle non-solid fill.)