The test_tightlayout.py::test_outward_ticks failure is explicitly testing that one can overlay a minor tick on top of a major tick, so I'll probably just remove that test (after looking into whether it is testing anything else relevant) (The patch below does not help because the test even requires a major label at x=0 that's overstruck by a minor tick:

diff --git i/lib/matplotlib/tests/test_tightlayout.py w/lib/matplotlib/tests/test_tightlayout.py
index 5898c1a94..a8f833f07 100644
--- i/lib/matplotlib/tests/test_tightlayout.py
+++ w/lib/matplotlib/tests/test_tightlayout.py
@@ -167,16 +167,14 @@ def test_outward_ticks():
     'Test automatic use of tight_layout'
     fig = plt.figure()
     ax = fig.add_subplot(221)
-    ax.xaxis.set_tick_params(tickdir='out', length=16, width=3)
-    ax.yaxis.set_tick_params(tickdir='out', length=16, width=3)
-    ax.xaxis.set_tick_params(
-        tickdir='out', length=32, width=3, tick1On=True, which='minor')
-    ax.yaxis.set_tick_params(
-        tickdir='out', length=32, width=3, tick1On=True, which='minor')
-    # The following minor ticks are not labelled, and they
-    # are drawn over the major ticks and labels--ugly!
-    ax.xaxis.set_ticks([0], minor=True)
-    ax.yaxis.set_ticks([0], minor=True)
+    for axis in [ax.xaxis, ax.yaxis]:
+        axis.set_ticks([0.2, 0.4, 0.6, 0.8, 1.0])
+        axis.set_tick_params(tickdir='out', length=16, width=3)
+        axis.set_ticks([0], minor=True)
+        # The following minor ticks are not labelled, and they
+        # are drawn over the major ticks and labels--ugly!
+        axis.set_tick_params(
+            which='minor', tick1On=True, tickdir='out', length=32, width=3)
     ax = fig.add_subplot(222)
     ax.xaxis.set_tick_params(tickdir='in', length=32, width=3)
     ax.yaxis.set_tick_params(tickdir='in', length=32, width=3)

)

The test_scale.py::test_logscales failure is (I believe?) due to the fact that the Symlog minor locator previously did not implement overstriking avoidance, so we ended up with overstruck major and minor ticks, which the svg rasterizer would pick up (one can examine the svg output to confirm); with this PR, the overstruck minor tick is absent, causing a tiny change in rasterization. Again, may be worth just killing the test if it's not testing anything else (after proper investigation).

Edit: test_logscales was introduced in #1247 to check that ax{v,h}line works with (sym)log scales. Rewrote it to use check_figures_equal.

Overall 👍 But another approach would have been to add a remove_ticks kwarg to locator.call. Not sure which approach is better but this way the locator could decide what to do with the ticks to remove. It’s also possible that the locator logic could do something interesting with the major ticks info.

Adding a remove_ticks=... to __call__ means going through a deprecation to not break third-party locators (ugh), and likely a bunch of locators will need to basically use the same code anyways (well, that can always be factored out in a helper method, but still...)

OTOH it does allow for really weird cases if you really want your custom locator to overstrike a major tick with a minor tick, not that I think there's a realistic use case... (the test_outwards_tick test is completely artificial.)

Oh, duh, you are right - I thought calling foo(unknown_kwarg='Boo') just ignored the kwarg, but thats only if the call signature has **kwargs which locator.__call__ doesn't have.

Now that I think of it, allowing API changes to have better backwards compatibility is actually a pretty good reason to have signatures with **kwargs.

For the "weird" cases, I could imagine knowing the major ticks could change the minor tick intervals. i.e. for dates, if you know the major ticks are days, making the minor ticks hours is useful. No doubt we already have logic for that, but it would be made easier by knowing the major ticks.

I guess compatibility could be maintained by a try block, but that is inelegant.

Now that I think of it, allowing API changes to have better backwards compatibility is actually a pretty good reason to have signatures with **kwargs.

That doesn't really help: for our own locators we can update them as desired, for third party locators we can't really force them to accept **kwargs as they would work fine without that.
A try: block introspecting the signature is probably doable, just a minor pain.

For the "weird" cases, I could imagine knowing the major ticks could change the minor tick intervals. i.e. for dates, if you know the major ticks are days, making the minor ticks hours is useful. No doubt we already have logic for that, but it would be made easier by knowing the major ticks.

Should probably have a look at what adhoc mechanisms are currently used and how this PR could or could not subsume them.

@jklymak I skimmed through dates.py and didn't see anything noticeable. Do you know of any example with interesting interactions between major and minor dates locators?

No I don’t think so, but you could imagine doing something like that....

Then I think I'd rather leave this PR as it is and worry about changing the signature of __call__ when an actual use case shows up...

Edited the other failing test (initially added in #5683) to check the axes positions instead.

Missed the fact that test_symlog{,2} suffers from the same overstriking problem as test_logscales. Dropped the png and svg tests, and kept the pdf baseline, as ghostscript appears not to pick up the overstriking, so the fundamental functionality (of symlog scales) is still tested.

I don't think there is a compelling need to have those tests make pdfs and svgs. OTOH, I bet the png still won't match because of anti-aliasing so maybe update the baseline image?

the png also fails due to antialiasing (likely), it is the pdf test that I kept; likely it works because ghostscript's rasterizer is not as good and does not perform the antialiasing correctly? :p

PS: I find it pretty funny that github's UI includes the svg files in the +/- lines count :)

Thinking again about adding remove_ticks to __call__ as a mechanism for inter-locator communication, I think that basically assumes (*) that the minor locator would always be used with the "corresponding" major locator (so that the minor locator can meaningfully interpret what is pass down to it). It is true that in general, a minor loglocator is used with a major loglocator (for example). But if you look at the issue that I mentioned in this PR, some of them come from people forcing major tick locations (effectively using a FixedLocator under the hood) and expecting the minor ticker to know not to put a tick there, so the assumption (*) does not hold.

If a minor locator really wants to know what a major locator did, it should probably(?) do something like 1) check that itself is the minor locator (self is self.axis.minor.locator) and then 2) call the major locator again to see what it outputs (self.axis.major.locator()).

I don't follow that argument. Why would it assume anything about what kind of locator it is or if its been used with a major locator? Its just saying: don't use these possible tick values, and maybe being clever about what to do between those tick values.

If you like, we could call it major_ticks and then that is the signal that the locator is a minor locator.

Again, I think we should have an actual example where passing the major ticks down is useful before going through the API change pain.
Also, self is self.axis.minor.locator is such an easy way to check whether you're the minor locator that I wonder why we missed it before [edit: I guess because that doesn't work for locators not associated with an axis, but I'm not sure we really care about that case...].

OK, getting in the weeds, but why does the locator care about its axis? We pass stuff around on a somewhat ad-hoc basis and this is one case where I'm not sure what the benefit is.

Right now, the locators need to know what the axis is because when you call locator(), they need to look up the axis limits; they also use it to consult axis.get_tick_space() (for determining the number of ticks).

The formatters need to know what the axis is to consult the axis limits.

I would like to make tickers independent of the axis (and always pass the axis down as argument) to make them reusable over multiple axises, but that's not going to happen here.

Tentatively milestoning as 3.1 as this already has one positive review (and fixes a longstanding bug), feel free to remilestone if it doesn't make it.

rebased

Anyone can merge after CI pass.

azure failure was download related, restarting.