[FR] Option to widen manual limits

[lllusion3418]

Sorry if I missed a previous issue.

Plots.jl version: 1.10.6

In this case I tried using ylims=(0,Inf) to indicate that i want the y-axis to start at 0 (because here the area under the blue curve somewhat matters):

This results in points at the maximum being cut off in the middle (and even the zero at the bottom isn't that pretty)! Because I couln't figure out another way except to calculate the maximum and use that times some factor (which I couldn't even do easily since they are a result of scatterhist()), I added plot!([0],[0], markersize=0, primary=false) to trick Plots.jl into thinking there was a point at y=0. This results in a somewhat nicer plot like this:

I get that lims are supposed to specify exact limits but I would think that the widen parameter would accomplish exactly what I want. Instead it gets ignored when custom limits are passed since it defaults to true (whereas if you did want the current behaviour you would also have had the option to set widen=false). Since it's probably a bit late to change that, could there at least be an option like widen = :force? If that's an option, it seems simple enough that I could implement it.

Another workaround I just found is using ylims() - adjusting that and passing it back in - but even that seems a bit complicated and hard to discover (is there a reason why there can't be some page just documenting all Plots.jl functions, or have I just somehow missed it? Examples are great but {x,y}lims() and e.g. mp4() don't seem to be mentioned anywhere).

Easy way to reproduce (with any backend):

scatter([1,2,3], [0,2,1], ylims=(0,Inf), legend=:none)

Edit: fwiw, this seems to work: ylims!(Plots.widen(ylims()...)) (unless you're using an logarithmic scale)

[fredcallaway]

Wow what a coincidence, I came here to post about this exact issue and it's already the most recent one!

I would put in a vote that widening would happen by default (i.e. not requiring widen=:force). Not respecting widen when passing limits is really just a bug, and I don't think backwards compatibility concerns should prevent fixing it.

[BeastyBlacksmith]

I think this is reasonable. I'd appreciate if you are up to make a PR. PRs to improve the documentation are also welcome!

[fredcallaway]

Given that someone had intentionally implemented default_should_widen to not widen when passing limits, it might be worth checking with other maintainers before accepting this. It's ultimately a subjective decision, and major plotting packages disagree on the correct behavior (matplotlib doesn't widen, ggplot does).

We can fall back on the widen=:force option if people don't agree with changing the default behavior.

[lllusion3418]

Personally I would prefer always defaulting to widen=true as suggested as well, but if backwards compatibility is a concern, another way might be to keep the current behavior as long as widen isn't passed explicitly (change the default to :auto or something) and always respect true/false if passed explicitly. I.e.:

• plot() == plot(widen = :auto) -> does widen
• plot(ylims = (a, b)) == plot(ylims = (a, b), widen = :auto) -> doesn't widen
• plot(widen = true) -> always widens regardless of limits
• plot(widen = false) -> never widens

Technically this would also be a breaking change, but why would anyone pass widen = true but not actually expect it to so.

[BeastyBlacksmith]

I like that a lot

[BeastyBlacksmith]

Actually what I really would like is a new axis attribute lets say limits_modifiers where I can mix and match like

julia> plot(1:5) |> Plots.xlims # still widen by default
(0.88, 5.12)

julia> plot(1:5, xlimits_modifiers = :round) |> Plots.xlims # in this case same as `limits_modifiers = false/nothing/:none`
(1.0, 5.0)

julia> plot(1:5, xlimits_modifiers = (:widen, :round) |> Plots.xlims
(0.0, 6.0)

julia> plot(1:5, xlimits_modifiers = (:symmetric, :widen) |> Plots.xlims
(-5.12, 5.12)

But I'm not sure we can do that non-breaking.

[fredcallaway]

Agreed. Something like that would be more consistent with Pots.jl style. However, this would be a substantially more involved change. Thus, I think it makes sense to merge my existing pull request, which implements @lllusion3418's :auto suggestion.

[BeastyBlacksmith]

Agreed. I'll put this in a seperate issue on the 2.0 milestone