Not sure if that's too much magic, but IMHO tick labels should always "point" to their tick. That would require different alignment depending on the rotation angle.

It could be an option not to expose explicit alignment but automatically choose it depending on the angle. (You could still use setp() if you need full control over all tick properties).

I totally agree w/ you on an automagical angle alignment as that's probably a common use case.

Labeling good first issue because it seems to have support from at least two devs and is somewhat independent, but medium difficulty because it's kind of involved:

1. adding more dispatch in

   matplotlib/lib/matplotlib/axes/_base.py

   Line 3358 in 4f5cacf

   def tick_params(self, axis='both', **kwargs):

2. adding more kwarg support to

   matplotlib/lib/matplotlib/axis.py

   Line 850 in 4f5cacf

   def set_tick_params(self, which='major', reset=False, **kw):

3. modify some methods on the tick class to support the new keywords

   matplotlib/lib/matplotlib/axis.py

   Line 35 in 4f5cacf

   class Tick(martist.Artist):

(ETA: probably in 3,2,1 order) + tests for all the new kwargs (which I think means image tests?)

(which I think means image tests?)

I think it can check [label.get_[vh]a() for label in get_ticklabels()]? (or via some similar new getter API if it gets added.)

(You could still use setp() if you need full control over all tick properties).

I've heard the setp excuse a lot all over this issue tracker and Stackoverflow in many contexts but it has a major flaw: For those of us working with interactive plots, we have to somehow make sure that setp is called after re-drawing when the ticks change.

Can anyone enlighten me what the reason is that we don't provide a mechanism to pass all keyword arguments to the ticks and labels through the various .tick_params and .set_tick_params methods? Is this just not implemented yet or are there major obstacles?

This ist mostly "just not implemented". However I except that there can be some corner cases (e.g. the alignment discussion above), where we might want to deviate from simply passing through.

While not a replacement, the new rotation modes in #28968 remove the need for explicit alignment control for one of the current most common use cases: fix tick alignment after rotation.

Hi @timhoffm ! I'm Evelyn, and am interested in helping resolve this issue. Can me and my team work on this?

Hi @evelyn-lo thanks for your interest. I'm still unclear whether we should support the alignment. If so, it would have the effect as described here, which should explicitly be mentioned as it may not be the obvious behavior.