Preserve set_extent across ticklen format

[cvanelteren]

Closes #517

This PR fixes a cartopy GeoAxes regression where calling format(..., ticklen=...) would silently override a previously set set_extent() by reapplying _update_extent() with the label-padding expansion. The new logic only refreshes extent when the user explicitly passes extent-related arguments (lonlim/latlim/boundinglat). Otherwise, tick length updates preserve the current extent by reapplying the existing view intervals. A regression test is included to ensure set_extent() remains stable across ticklen-only format calls.

[cvanelteren]

Failures of the tests can be ignored btw -- docs are fixed on a different PR.

[gepcel]

As of commit 677aec2, I'm not quite following your logic, but I don't think issue 517 has been resolved. The extent messing up may not be caused by "label-padding expansion", and the bug was recently introduced into the code.

[gepcel]

This might be the same bug, so I posted here.

import ultraplot as pplt
print("Ultraplot version:", pplt.__version__)
fig,ax=pplt.subplot(proj='cyl')
ax.format(labels='both', ticklen=.5)

Set ticklen override labels='both'.

[cvanelteren]

Whwn setting extend through format, a small space will be added to ensure that the labels will be visible. It is a thing that was present in proplot, and caused some issues for users in the past. When extent is used now, it will override it. I can do some testing to see if we should get rid of the epsilon all together or not.

[cvanelteren]

This might be the same bug, so I posted here.

import ultraplot as pplt

print("Ultraplot version:", pplt.__version__)

fig,ax=pplt.subplot(proj='cyl')

ax.format(labels='both', ticklen=.5)

Set ticklen override labels='both'.

What's the issue here?

[cvanelteren]

Ah I see the issue indeed -- sorry just woke up. That is a separate issue.

[gepcel]

Whwn setting extend through format, a small space will be added to ensure that the labels will be visible. It is a thing that was present in proplot, and caused some issues for users in the past. When extent is used now, it will override it. I can do some testing to see if we should get rid of the epsilon all together or not.

Oh, I see. I didn't notice the small space added for label visiblity. What I meant was some format stuff caused the extent changed a lot, and format(lonlim=.., latlim=..) didn't respect the extent.

[cvanelteren]

The code you provided in that issue will now respect it after you set with extent but still uses the default epsilon stuff for when format is used

[cvanelteren]

More succintly your code now produces:

 python test.py
After set extent using lonlim and latlim: (0.22999999999999998, 2.42, 0.31000000000000005, 2.4699999999999998)
After set extent using set_extent       : (0.73, 1.92, 0.81, 1.97)
After format something other than extent: (0.73, 1.92, 0.81, 1.97)

[gepcel]

Yes, the result shows exactly it's not.

# %%
import ultraplot as pplt
fig, ax = pplt.subplot(proj='cyl')
ax.format(lonlim=[0.73, 1.92], latlim=[0.81, 1.97])
print(pplt.__version__)
print("After set extent using lonlim and latlim:",ax.get_extent())

the result is:

1.70.1.dev61+g677aec2e7
After set extent using lonlim and latlim: (0.22999999999999998, 2.42, 0.31000000000000005, 2.4699999999999998)

while it should be : (0.73, 1.92, 0.81, 1.97)

[cvanelteren]

As I indicated above the default formatting will add this epsilon if you add it through format. What this PR does is respect the limits after a set_extent is called -- it does not alter the behavior of the epsilon being added when called using .format. A change like that would affects users that may prefer the epsilon being added. We could add an epsilon parameter together with an rc to override this.

[gepcel]

As the doc indicats, ax.format(lonlim=(x1, x2), latlim=(y1, y2) should get the geoax extent as (x1, x2, y1, y2), but it's not now.

And this issue doesn't come from proplot, though I haven't test every version, but it's recently. For example, in ultraplot v1.66.0, the issue is not there yet. Might came from v1.70.0

[cvanelteren]

Ok @gepcel aligned them now

After set extent using lonlim and latlim: (0.73, 1.92, 0.81, 1.97)
After set extent using set_extent       : (0.73, 1.92, 0.81, 1.97)
After format something other than extent: (0.73, 1.92, 0.81, 1.97)

[gepcel]

I'm not very proficient with Git workflows yet. I see here it means revert and drop changes from pull #520? Or keep pull 520?

[cvanelteren]

There is but I manually fixed it. It is fine for now I think I'm spreading myself too thing recently