sidebar: air inside it, the way panes have padding (tab_bar_padding)

`padding` is a pane's: the ring between a frame and the text it holds, in rows
times gap_aspect so a `1` looks square around a block of prose. Handing the
same knob to the sidebar looked tempting and is wrong twice over. The sidebar
is chrome, not a pane, and its width is fixed by tab_bar_width -- so `padding
1` would quietly eat four of a sixteen-column strip (two cells a side, aspect
included) and shorten every tab name, because somebody wanted their terminal
text to breathe. And its two axes are not one idea: the columns are an indent
for labels, the rows are air above a list.

So tab_bar_padding, its own knob in the family the rest of the sidebar's air
already lives in (tab_bar_pad, tab_gap, newtab_pad), taking the same 1/2/4
CSS-order values as `padding` -- one reader for both, so they cannot drift
into meaning different things -- but counted in cells.

The default `0 1` is what the sidebar already drew: that one column is where
every label's leading space has been hard-coded since the sidebar existed, and
moving it into a setting is what makes `tab_bar_padding 0` possible at all --
names flush against the frame, which was not previously a thing anyone could
ask for. The statuses, the `+ new tab` row and the pane count follow the same
indent, since they were each carrying their own copy of that space.

It is air *inside* the plate: a tab's fill still spans the whole row and the
whole row is still the hit, because the row is what you click and a highlight
that stopped short of the frame would read as a highlighted word rather than a
chosen row. The bottom rows are given up when the strip is short of them, like
every other piece of air in here.

tab_bar_pad is the older name for the top component alone. It still works,
still means exactly that, and wins where a config writes both -- it is the
more specific of the two. The dump writes tab_bar_padding and mentions it.

1 files changed, 19 insertions, 5 deletions

diff --git a/include/config.h b/include/config.h
index 92f33a1..47e48a7 100644
--- a/include/config.h
+++ b/include/config.h
@@ -365,11 +365,25 @@ typedef struct {
    * Ignored on the top strip, where a tab is only as wide as its label and
    * there is no room to align anything in. */
   int tab_bar_index;
-  /* Rows a sidebar leaves blank above its first tab. Air for anyone who finds
-   * a list starting in the very corner cramped -- or room for a terminal's
-   * own window buttons when the multiplexer fills a borderless window.
-   * Ignored for top, which has exactly one row and no air to give. */
-  uint16_t tab_bar_pad;
+  /* Air inside a sidebar, between its frame and the list in it, per side and
+   * in CELLS: rows above and below, columns left and right. Written as 1, 2
+   * or 4 values in CSS order like `padding`, and in cells rather than
+   * `padding`'s rows-times-gap_aspect, because this is not a ring around a
+   * block of text -- the two sides do different jobs. The columns are an
+   * indent for labels and statuses, and the rows are air above the first tab
+   * and below the last thing in the strip.
+   *
+   * The left column is 1 by default, which is where every label's leading
+   * space used to be hard-coded; 0 puts the names against the frame.
+   *
+   * It is *inside the plate*: a tab's fill still spans the whole row, because
+   * the row is the click target and a highlight that stops short of the edge
+   * reads as a highlighted word rather than a chosen row.
+   *
+   * `tab_bar_pad` is the older name for the top alone and still works; where
+   * both are written the more specific one wins. Ignored for the top strip,
+   * which has exactly one row and no air to give. */
+  uint16_t tab_pad_top, tab_pad_right, tab_pad_bottom, tab_pad_left;
   /* Blank rows between one tab and the next, so a list of tabs each carrying
    * a paragraph of status reads as separate entries rather than as one
    * column of text. Sidebars only: the top strip is a single row, where the