George Thomas

A little, but if you're able to commit to GHC 9.2, those rules are redundant with `ImpredicativeTypes`.

Okay, actually, a `$` before the `R` largely solves the excess vertical space. Similar use of `$` works for all similar examples I can think of. But I can't see...

> But I can't see a way around the excess horizontal space. Some speak of a cure for these sorts of ills. But we would not contemplate such heresy...

> Fourmolu doesn't, and IMO shouldn't, do anything different here Why do you think that? I'm not so sure. We have the opportunity to do something better downstream, as long...

> I can't imagine why Ormolu wouldnt want to fix this though. They're just generally past the point of making big style changes*, so I assume anything remaining that annoys...

Thanks for linking https://github.com/tweag/ormolu/issues/692 anyway, as I hadn't seen it until now. And while this issue is slightly more general, you've explained the problem more clearly than I managed.

I'm reopening since I still care about this a lot, I know from various conversations that I'm not the only one, and it's clear at this point that upstream aren't...

Yeah, I've ended up often using `cabal repl -b pretty-simple --repl-options="-interactive-print Text.Pretty.Simple.pPrintForceColor"` because the `.ghci` solution doesn't always work (see https://github.com/haskell/cabal/issues/7789).

I don't think this is specific to MS browsers, and it also applies in the vertical case. In Firefox, I find that the element always overflows with the default width...

It would also be nice to make the [step size](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#controlling_step_size) configurable for number inputs. We set this to `"any"` in c6ebd4cd42e7b90eb3faa8b344764874cabeda74.