sl0ppty: a tab is something you can name and move

Tabs had names -- a layout could set one, the control API could set one --
and no way to type one. A tab you made yourself was stuck being a number.
And the strip's order was the order tabs happened to be created in, forever.

Both are the same gesture as the pane equivalent, on the other thing that
has a name:

  double-click a tab   rename it in place, in its own cell in the strip
  drag a tab           move it along the strip

They land together because they share the machinery they are built on, and
splitting them would have meant writing the shared half twice.

The rename editor is the pane's, generalised from "renaming a pane" to
"renaming a pane or a tab" -- one editor with a subject rather than two that
would drift. Enter keeps, Escape abandons, clicking away commits, empty
gives the tab back its number. It is seeded with the name only: a pane seeds
from its title because a title is always something, but a tab shows its
*number* until it is named, and offering "3" to backspace over would be
offering to edit the wrong thing.

The drag is the existing drag machine's third verb, and it reorders **as you
go**. The strip is the only thing that could show an insertion point, and a
strip already showing the result needs no such invention -- no ghost tab, no
caret, nothing remembered between frames. Dragging off the strip is not a
cancel: it is simply not a place to put a tab.

Two things that were not obvious until they were written down:

- pane ids and tab ids are separate sequences, so pane 2 and tab 2 both
  exist. The double-click detector remembered only the id, so a click on one
  followed by a click on the other read as a double-click on whichever came
  second. It remembers the kind too now, and the test asserts the ids really
  do collide before asserting they are told apart -- otherwise it would
  quietly stop testing anything the day the sequences diverge.
- `cur` is a *position*, not an identity, so a move has to recompute it.
  Carried across, you would be looking at whichever tab slid into the index
  you used to be at.

`{"cmd":"move-tab","id":N,"index":M}` does the same thing from a script, and
is what tests the arithmetic from a tab that is not the one being moved --
the case a drag can never produce, because a drag selects what it grabs.

1 files changed, 3 insertions, 0 deletions

diff --git a/src/app.h b/src/app.h
index 33756e7..e118691 100644
--- a/src/app.h
+++ b/src/app.h
@@ -69,6 +69,9 @@ void app_cycle_tab(app_t *a, int delta);
 size_t app_tab_count(const app_t *a);
 bool app_close_tab(app_t *a, uint32_t id);
 bool app_set_tab_name(app_t *a, uint32_t id, const char *name);
+/* Put a tab at a different position in the strip, 0-based. The strip is the
+ * order, so this is what dragging one does; you stay in the tab you were in. */
+bool app_move_tab(app_t *a, uint32_t id, size_t index);
 
 /* Purposes (D8). `declared` means "from a layout/control API": it outranks an
  * in-band purpose and locks it, so a pane cannot relabel itself afterwards.