I'm confused by this. I would think you'd only want the warning if there is a minus sign? Or are we claiming people can't putcmr10 in their font family without getting a warning?

Or are we claiming people can't putcmr10 in their font family without getting a warning?

We're claiming thatcmr10 is not intended for standalone use (many required glyphs are not present in that file but in others), and it only makes sense when used with mathtext.

For ticks, we need to force axes to use mathtext, hence, the warning.

Then should there also be a warning when the rcParam is validated?

By the time we're validating rcParams, I don't think we can identify the use of mathtext (one could explicitly passuseMathText to True and we would still emit the warning if we did this at rcParams level)

I guess I'm finding this all a little rickety. When folks wantcmr10 they basically want a suite of LaTeX math fonts? Is there a better strategy here than just special casing sometimes, and not others? Can we takecmr10 to meancmr10+cmbsy10+ etc in general?

Can we take cmr10 to mean cmr10+cmbsy10+ etc in general?

This more or less means (some part of)@aitikgupta's GSOC: currently, non-mathtext textcannot use multiple fonts on a single text object at all.

We would also need to check font.{families}, for example, the repro code at#16995 (comment) before merging.

Sorry, are you saying this is not ready for review? I'll move to draft, but feel free to move back

LGTM, but do we want a test?

Do we test_api warnings?
I could add a simple triggering test in test_ticker.py

Interesting, this breakstest_usetex_no_warn in test_legend.py:

^when the font isComputer Modern, I'm not entirely sure how to tackle this (maybe change 'Computer Modern' to 'cmr10'?)

The warning arises because test_legend is using usetex, which uses different family names (here "Computer Modern", not "cmr10"), which can be found by texmanager but not by the normal font system. In practice, what this likely means here is that the call tofindfont added by this PR must be wrapped in something that suppresses logging warnings, as we do not want to emit a warning (about using use_mathtext) if the font cannot be found at all (because in that case it certainly doesn't match cmr10).

Hmm, something weird is going on with warnings, spent some trying to get this work:

withwarnings.catch_warnings():warnings.filterwarnings("ignore")_log.warn("This is not ignored.")# <---ufont=mpl.font_manager.findfont(mpl.font_manager.FontProperties(mpl.rcParams["font.family"]))# ^Neither does it suppress the `findfont` warningifufont==str(cbook._get_data_path("fonts/ttf/cmr10.ttf")):_api.warn_external("cmr10 font should...."    )

Moreover, if we use the context manager, the warnings are no longer "just once".
(this happens even if we do absolutely nothing inside it):

withwarnings.catch_warnings():warnings.filterwarnings("ignore")# Do Nothingufont=mpl.font_manager.findfont(mpl.font_manager.FontProperties(mpl.rcParams["font.family"]))ifufont==str(cbook._get_data_path("fonts/ttf/cmr10.ttf")):_api.warn_external("cmr10 font should..."    )

^Output contains a lot of "cmr10 font should..." (since we call multiple instances ofScalarFormatter)

Previously, without using the context manager:

ufont=mpl.font_manager.findfont(mpl.font_manager.FontProperties(mpl.rcParams["font.family"]))ifufont==str(cbook._get_data_path("fonts/ttf/cmr10.ttf")):_api.warn_external("cmr10 font should..."    )

^Output contains only one "cmr10 font should..." (even when multiple instances ofScalarFormatter are called)

I haven't fully unraveled your points, but the fact that warnings.catch_warnings() doesn't catch log.warn() is expected (logging and warnings are two different systems). (But I did miss that initially.)
As it turns out findfont uses logging, and suppressing the logwarn is a bit annoying (I guess technically the correct solution would be to temporarily install a logging filter, but ugh); in practice I think the simpler solution may be to callfindfont(..., fallback_to_default=False) which doesn't emit any logwarn, but instead throws a ValueError if no font matches (and then you need to catch that ValueError and treat that as OK, as it means that the user-selected font certainly doesn't match cmr10).

(The font_manager API is turning out to be not really optimal for this use case, but that's another story...)

Interesting, I started off on the fundamentally wrong track!
I'll update the PR

done!