I like this and agree it makes a lot more sense, but...

If someone callsformatter() for some reason (old custom axis of some sort?) it still needs to do the interdependent calculation, doesn’t it? I’m just not at all clear that we could move the interdependent code fromLogFormatter.__call__ into this function without breaking someone’s code. I’m also not clear what now goes in__call__

ForConciseDateFormatter, you'd just write a stub__call__ that callsformat_ticks and extracts the single relevant value (perhaps the base__call__ could even check whetherformat_ticks is overridden by the subclass (the check is necessary to avoid infinite recursion betweenformat_ticks and__call__...), and, if it is, defer to it -- it's not that hard to do). Yes, that's a bit slower, but that only affects third party callers and simplifies the implementation quite a bit so I think it's worth it.
With this design, one would need to implement either__call__ orformat_ticks, but not both (ignoring issues such as formattingcursor values, which can also be fixed). For LogFormatter we just need to check whether it's indeed better to move the logic toformat_ticks (and again just make__call__ defer to it).

So, can you implementLogFormatter with the new method?

As per above - needs change log and ideally a real-world example...

The real-world example is basically ConciseDateFormatter (happy to rewrite it using this API after the ConciseDateFormatter is merged).

Happy to do it the other way around if that makes more sense.

I think it makes more sense to get ConciseDate in first and then we'll be better able to see whether this PR fixes the design properly, or if we need some other API.

ping@anntzer ConciseDateFormatter is now in, so this can be looked at again?

I'm not sure how this plays with the issues of the minor locator ignoring major ticks. They are separate issues, right?

Pushed an adaptation of ConciseDateFormatter using the format_ticks API, it is a bit simpler.
This PR only touches formatters, so has nothing to do with locators.

LGTM! Still needs the API change note?

added whatsnew

I think I made a mistake while reimplementing ConciseDateFormatter; namely, the "compression" should be used regardless of whether show_offset is True or False and show_offset only controls whether offset_string is set. Force-pushed a fix restoring the behavior as intended by@jklymak.

ooops, thanks for catching that....

Travis failure is the unrelated, spurious wqy-zenhei.ttc test.

Apologies if not the right place. This PR has the following side effect:

fig,ax=plt.subplots()data=np.clip(randn(250,250)*1000,0,1000)cax=ax.imshow(data,norm=mpl.colors.LogNorm(vmin=1,vmax=1000))cbar=fig.colorbar(cax,format='%d')cbar.minorticks_off()cbar.set_ticks([5,10,100])plt.show()

Prior to this PR, minor ticks would remain off afterset_ticks when they had been turned off. After this PR, they come back on.

Edit: Comment is wrong, this PR did not change this.