| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
This will definitely not have any consequences.
|
|
|
|
This code is meant to replace a rectangle that is the result of
an intersection with a spanning-infinitely-left region, i.e.
the opportunity area for placing a tooltip to the left of its
hoverable, with a narrow channel so that its `x` is the
appropriate left alignment for the tooltip.
That behavior is working correctly (hopefully), but the fallback
is that it *shouldn't* be modifying a rectangle which intersected
with a spanning-infinitely-right region. We were mistakenly
dropping anything to do with the intersection and returning
the region rectangle instead, which broke vertical alignment
any time a tooltip is aligned to the right of the hoverable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Generators don't necessarily make the moset sense for splitting
an operation into just two steps, instead of one that might
recurse in a more complex fashion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Includes baseline rectangle computation and actually applying an
arbitrary position to a tooltip.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Instead of the flipwise direction.
|
|
|
|
|
|
|
|
Lets us build up symbolToStable simultaneously, which we use when
computing unstableSortIndices, officially making it "not magic".
|
