Tab lists its matches in columns, and says what it can in colour

Tab's listing was six instructions: print the name, print two spaces. It
was the crown of this shell for a while and looks plain next to ls.

Columns cost NOTHING EXTRA. Tab already walks its candidates twice - once
to find the answer, once to show the matches, and tabRunSources exists
because those are the same walk asked two questions. The longest match is
counted on the first, which already visits every one of them, so the
listing needs no walk of its own to know how wide a column should be.
Padding goes before a name rather than after, so a row ends on a name.

Directories are blue and the shell's own commands are green. Both are
free: Tab appends the separator itself, and a built-in is not a file at
all - which is also the only way anybody could know it will run.

A FILE IS NOT COLOURED, and that is a decision. Whether a file will run
is a read of its first block, which is what ls does and what makes ls
cost twice what it otherwise would. Here it would be worse than slow:
candidates are offered from inside a directory walk, and looking a file
up would overwrite the very fields holding the walk's own position. Doing
it safely means holding every candidate name in memory, which is a buffer
the shell would carry whether anybody pressed Tab or not - and ls is one
keystroke away. A Tab press already costs about 200,000 cycles, so the
read was not the objection.

---- And the machine could no longer build itself ----

Found by make test, not by reading. The native assembler ran out of room
for label names on cosmos.asm: 16,758 bytes against 16,384. The index was
1,341 of 1,536 in the same breath.

Which is scratch.asm's own warning happening a second time - "two
ceilings a hundred bytes apart look like one ceiling until the first is
lifted" - so both were raised, out of the seventeen kilobyte page that
file deliberately left unclaimed against exactly this. Names to 26,624
and the index to 2,048, both left about a third clear, with 1,792 bytes
still unclaimed for the same reason.

A name is thirteen bytes on average and an index entry is four, so the
arena will always be the one that speaks first. That is now written down
where the two numbers are.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

Programs/CosmOS/Assembler/scratch.asm

@@ -20,10 +20,10 @@
 ; bad enough; a stale number sitting next to the correction is worse, because whichever
 ; one a reader takes is a coin toss.
 ;
-;   0x5000  6144   the label index, 1536 entries of four
-;   0x6800 16384   the label names, packed end to end
-;   0xA800   256   one block of the output file, on its way to the disk
-;   0xA900 17152   free
+;   0x5000  8192   the label index, 2048 entries of four
+;   0x7000 26624   the label names, packed end to end
+;   0xD800   256   one block of the output file, on its way to the disk
+;   0xD900  1792   free
 ;   0xE000  1792   the vector names, 64 entries of twenty eight
 ;   0xE700  2048   the reader's stack, six levels of 301
 ;   0xEF00   368   which files have been included, sixteen names of 23
@@ -69,6 +69,17 @@
 ; among buffers that do not need it, because an unclaimed page is available to whichever
 ; one turns out to want it.
 ;
+; ---- And one turned out to want it ----
+;
+; Sixteen kilobytes of names was half full when that was written and ran out on 2026-09-06,
+; on an ordinary day's work on the shell: 16,758 bytes of name against 16,384. The index was
+; 1,341 of 1,536 in the same breath, which is the paragraph above this one happening again -
+; two ceilings, and lifting only the one that spoke would have bought two hundred labels.
+;
+; So both, out of the free page, and both left at about a third clear rather than at half:
+; the names to 26,624 and the index to 2,048. What is left over is 1,792 bytes, kept
+; unclaimed for the same reason the seventeen kilobytes were.
+;
 ; That ends at 0xF070, with the Stack coming down from 0xFFFF above it - nearly four
 ; kilobytes, against the tens of bytes of CALL frames this ever nests.
 ;
@@ -78,16 +89,17 @@
 ; list moved up rather than the stack simply being asked to fit.
 ;
 ; THE TWO THINGS THAT DECIDE THESE SIZES are the largest program it will be asked to build
-; and the largest one it will be asked to read. CosmOS is 475 labels and 9,564 bytes of
-; output; the assembler itself is 555 labels, about 6,800 bytes of name and 11,648 of output. The
-; second is bigger than the first, which is worth knowing: the hardest thing this assembles
-; is not the operating system, it is itself.
+; and the largest one it will be asked to read. Measured 2026-09-06: CosmOS is 1,341 labels
+; and 16,758 bytes of name, and the assembler itself is far smaller. It was the other way
+; round when this file was written - "the hardest thing this assembles is not the operating
+; system, it is itself" - and the system has grown past it since. The numbers here are worth
+; measuring again rather than believing, which is why they carry a date.
 ScratchLabIndex:
   0x50 0x00
 ScratchLabArena:
-  0x68 0x00
+  0x70 0x00
 ScratchWindow:
-  0xA8 0x00
+  0xD8 0x00
 ScratchVecNames:
   0xE0 0x00
 ScratchSrcStack: