sl0ppty: a horizontal handle gets heavier, not taller

The armed handle grew by one cell into the pane on all four sides, which is one
change on two axes and therefore two different results. A cell is about twice as
tall as it is wide -- the fact `gap_aspect` exists for, and the one the split
picker measures its longer side by -- so the extra column on a left or right
edge read as a thicker line, and the extra row on a top or bottom edge read as a
wall. It also spent a row of somebody's output to say something the glyph was
already saying: `█` is the heaviest thing one cell can draw, and against `━` it
needs no help.

So only the upright sides widen now. A horizontal handle stays on its own row.
That also removes its claim on a content cell, which is why the inner-strip hit
is registered on those two sides only -- the paint and the hit still describe the
same rect, which is the whole reason the guide registers what it thickens.

Verified: `make retest`, 1807 checks, all green -- six new, pinning the asymmetry
in both directions: the top and bottom handles occupy exactly the row their
border is on, the left and right ones exactly two columns, and the inner column
of each upright handle hit-tests as that border rather than as the pane.

Measured on a live session rather than argued: hovering the bottom border of a
116x36 pane puts seven block cells on row 37 and no others, inside the `━` rule;
hovering the left border puts them on rows 16-22 across columns 2 and 3.

1 files changed, 11 insertions, 7 deletions

diff --git a/src/app.c b/src/app.c
index ccb86ac..8754b35 100644
--- a/src/app.c
+++ b/src/app.c
@@ -3456,8 +3456,17 @@ static void draw_split_guide(app_t *a, screen_t *s, node_t *leaf) {
       screen_text(s, x, by, "\u2501", hi, NO_COLOR, ATTR_BOLD);
   }
 
-  /* The handle, thickened by one cell into the pane, and the hit for that inner
-   * strip registered here because *this* is the frame in which it is that size.
+  /* The handle, made heavier, and — where that means claiming a cell the pane
+   * was using — the hit for it registered here, because *this* is the frame in
+   * which it is that size.
+   *
+   * Only the upright sides grow. A cell is about twice as tall as it is wide
+   * (`gap_aspect`, and the split picker leans on the same fact), so one extra
+   * column is a nudge and one extra row is a slab: a two-row bar across a top or
+   * bottom border reads as a wall rather than as a thicker line, and eats a row
+   * of somebody's output to say so. The block glyph is already the heaviest
+   * thing a single cell can draw, and against `━` it is unmistakable, so a
+   * horizontal handle stays one row and says it with ink instead of size.
    *
    * The rect is read back from the list rather than recomputed: draw_frame
    * placed it, and for the top row it places it wherever the title and the
@@ -3475,11 +3484,6 @@ static void draw_split_guide(app_t *a, screen_t *s, node_t *leaf) {
       hit_add(&s->hits, in, h.y, 1, h.h, act);
       if (in < h.x) h.x = in;
       h.w = 2;
-    } else {
-      uint16_t in = side == 't' ? (uint16_t)(h.y + 1) : (uint16_t)(h.y - 1);
-      hit_add(&s->hits, h.x, in, h.w, 1, act);
-      if (in < h.y) h.y = in;
-      h.h = 2;
     }
     for (uint16_t y = h.y; y < h.y + h.h; y++) {
       for (uint16_t x = h.x; x < h.x + h.w; x++) {