sl0ppty: the split arrow belongs on the button

The arrow rode the middle of the dashed boundary line, which put the two halves
of one message in two places: the handle said *press here* and a glyph out in the
middle of the pane said *this is what happens*. It also meant the direction was
unreadable until you were already on the target, since the dashed line is stage
two of the hover.

So the arrow moves into the handle and the boundary line goes back to being a
plain boundary -- which is the honest shape for it anyway: it is the *edge* of the
pane you are about to make, and an edge has no middle worth marking. The handle
is now one object that explains itself, and because the handle is drawn from the
first stage, brushing any part of an edge tells you where its button is and which
way that button splits, without previewing a boundary nobody asked about.

Knocked out with ATTR_INVERSE rather than drawn in a second colour: the bar is
solid `guide`, so a `guide` glyph on top of it would have been invisible, and
inverting gets contrast that follows whatever colour the theme sets for no new
knob. Along the handle the arrow sits in the middle, where the pointer is aiming.
Across it -- a distinction only the upright pair has, being the two that grow a
second cell -- it sits on the edge's own cell rather than the one over the
content, because it marks a boundary and the boundary lands on the frame.

Verified: `make retest`, **1873 checks measured** (`test_split_ux.py` 100 of
them), all green. The test that pinned the arrow to the dashed line is now the
test that pins it to the handle, on all four sides, plus one that it is legible
from the first stage with no boundary drawn.

Checked live on a 116x36 pane: `◄█` at column 2 and `█►` at column 117 on the
middle row of their bars, `━━━███▼███━━━` on the bottom border's single row, and
-- the case that shows why this is worth it -- hovering the *far left* of the top
row draws `███▲███` at column 85, where the handle actually is, having dodged a
centred title.

A note on the two commits before this one: their messages quote 1801 and 1807
checks, which were carried over from earlier in the session rather than measured.
The figure was 1865 at that point. The code and the tests were right; the numbers
in those two messages were not.

1 files changed, 38 insertions, 15 deletions

diff --git a/src/app.c b/src/app.c
index 8754b35..e3ca287 100644
--- a/src/app.c
+++ b/src/app.c
@@ -3485,38 +3485,61 @@ static void draw_split_guide(app_t *a, screen_t *s, node_t *leaf) {
       if (in < h.x) h.x = in;
       h.w = 2;
     }
+    /* The button carries its own verb. The arrow used to ride the dashed line,
+     * which put the two halves of the message in two places: the handle said
+     * *press here* and something over in the middle of the pane said *this is
+     * what happens*. On the handle it is one object that explains itself, and it
+     * is legible from the first stage -- brushing an edge now tells you which way
+     * that button splits without drawing a boundary you did not ask about.
+     *
+     * Knocked out of the bar with ATTR_INVERSE rather than drawn in a second
+     * colour: the block is solid `guide`, so a `guide` glyph on top of it would
+     * be invisible, and inverting spends no new theme knob to get contrast that
+     * follows whatever colour you set.
+     *
+     * Pointers rather than the matching triangles for left and right: U+25C0 and
+     * U+25B6 carry emoji presentation and terminals widely render them
+     * double-width, and screen_text books every chrome glyph as one cell — so a
+     * cell that draws as two would shift the rest of the row. U+25B2 is already
+     * the scroll indicator, so the vertical pair is known good here. */
+    const char *arrow = side == 'l'   ? "\u25c4"
+                        : side == 'r' ? "\u25ba"
+                        : side == 't' ? "\u25b2"
+                                      : "\u25bc";
+    /* Along the handle it goes in the middle, which is where the pointer is
+     * aiming. Across it, on the edge's own cell rather than the one over the
+     * content: the arrow marks a boundary, and the boundary lands on the frame.
+     * That distinction only exists on the upright pair, since those are the two
+     * that grew a second cell. */
+    bool vert = side == 'l' || side == 'r';
+    uint16_t ax = vert ? (side == 'l' ? h.x : (uint16_t)(h.x + h.w - 1))
+                       : (uint16_t)(h.x + h.w / 2);
+    uint16_t ay = vert ? (uint16_t)(h.y + h.h / 2) : h.y;
     for (uint16_t y = h.y; y < h.y + h.h; y++) {
       for (uint16_t x = h.x; x < h.x + h.w; x++) {
         const char *own = hit_test(&s->hits, x, y);
-        if (own && strcmp(own, act) == 0)
-          screen_text(s, x, y, "\u2588", hi, NO_COLOR, ATTR_BOLD);
+        if (!own || strcmp(own, act) != 0) continue;
+        bool tip = x == ax && y == ay;
+        screen_text(s, x, y, tip ? arrow : "\u2588", hi, NO_COLOR,
+                    tip ? (uint16_t)(ATTR_BOLD | ATTR_INVERSE) : ATTR_BOLD);
       }
     }
   }
 
   if (!on_handle) return;
 
-  /* Stage two: an arrow on the new boundary, pointing at the side the new pane
-   * will take. The dashed line says where, and on its own leaves which half is
-   * the new one to be inferred from which border you happen to be touching.
-   *
-   * Pointers rather than the matching triangles for left and right: U+25C0 and
-   * U+25B6 carry emoji presentation and terminals widely render them
-   * double-width, and screen_text books every chrome glyph as one cell — so a
-   * cell that draws as two would shift the rest of the row. U+25B2 is already
-   * the scroll indicator, so the vertical pair is known good here. */
+  /* Stage two: where the new boundary lands, and nothing about direction -- the
+   * handle is holding that end of the message now. A plain dashed line is also
+   * the honest shape for it: it is the *edge* of the new pane, and an edge has
+   * no middle worth marking. */
   if (side == 'l' || side == 'r') {
     uint16_t mid = (uint16_t)(r.x + r.w / 2);
     for (uint16_t y = (uint16_t)(r.y + 1); y < y1; y++)
       screen_text(s, mid, y, "\u254e", hi, NO_COLOR, 0);
-    screen_text(s, mid, (uint16_t)(r.y + r.h / 2),
-                side == 'l' ? "\u25c4" : "\u25ba", hi, NO_COLOR, ATTR_BOLD);
   } else {
     uint16_t mid = (uint16_t)(r.y + r.h / 2);
     for (uint16_t x = (uint16_t)(r.x + 1); x < x1; x++)
       screen_text(s, x, mid, "\u254c", hi, NO_COLOR, 0);
-    screen_text(s, (uint16_t)(r.x + r.w / 2), mid,
-                side == 't' ? "\u25b2" : "\u25bc", hi, NO_COLOR, ATTR_BOLD);
   }
 }