Tim Hoffmann

Semi-OT: Process-wise we are doing something wrong here. The issue has now 10 PRs trying to address it. This is quite unreasonable and a waste of ressources. I'm not sure...

> hit a bunch of slopes and ylimit scales. AFAICS, we don’t have slope- or scale-dependent code (other than the special case 0), I.e. we don’t expect the behavior to...

@scottshambaugh @oscargus What’s the semantic difference between an explicit slope and a calculated one? AFAICS it’s just how the user has defined the line and small values can equally happen...

I'm inclined to go with the simple == 0 approach. We don't know what cases a small tolerance would help with. But we know that using tolerances here will modify...

I'm not clear what the "first approach" is. I've suggested to simply replace `if np.isclose(slope, 0)` by `if slope == 0`. I.e. - only prevent the division by zero for...

I'm not an expert in this topic, so do we really need all those impementations? I assume 99% of users just want that "it works", which means one good rotation...

> Would a selection on the toolbar be better? IMHO a rcParam for the rotation mode should be good enough (if we need multiple options). You can set this globally...

What could speak against python style files: - security: Users can inject arbitrary code. - IMHO there are various other ways to do this. (If it's really of concern, one...

This seems inconsistent and likely we haven't thought about it when subfigures were introduced. Intuitively, I'd recommend the following behavior: `get_figure()` returns the closest (sub)figure. If we were to go...

> So I wonder if the correct course of action is to override `get_figure` to return the parent figure, but keep `self.figure` as-is. In hindsight, it should have been private,...