Say what went wrong, and give the file tools room for a path

The makefile on the disk was fine. "Makefile" is not "makefile", and SBFS names are case
sensitive - but neither tool said so, and both failed in ways that pointed somewhere else.

MORE PRINTED A NUMBER THAT MEANT NOTHING. "cannot find the file, error 2" invents a
vocabulary the system does not have: the filesystem library documents its answer as zero or
not zero, never as a code, so 2 could not be looked up anywhere. It says "there is no file by
that name" now, which is the only way opening fails that a person can do anything about, and
is nearly always a name typed slightly wrong.

EDIT SAID "0 LINES", which is also what an empty file that IS on the disk says. A name typed
slightly wrong therefore looked exactly like the document you meant to open, right up until
you saved it somewhere new. It says "new file" instead.

Two bugs came out of writing that, and both are worth more than the feature.

The first is mine and the label lied to me: loadNothing is not where a load FAILS, it is
where every load FINISHES, reached at the end of splitLast on files that opened perfectly
well. A flag set there on the strength of the name was set on everything. It is called
loadDone now, and the failure has its own name.

The second is older and general: a program is loaded once and may be run many times, so
"load Edit.sbx" then "run" twice is two sessions over one copy of the Data Segment. Anything
a session changes has to be put back by the session. A zero written in the Data Segment is
the state a program starts in the first time and never again - and cosmosEdit runs Edit twice
from one load, which is why it caught it immediately.

AND THE FILE TOOLS COULD NOT ADDRESS THE TREE THEY NOW HAVE. Edit took 23 characters of name
and More and Type took 29, which were right when everything lived in the root. With the
sources mirrored onto the disk, "/Source/CosmOS/Assembler/classify.asm" is an ordinary thing
to type - thirty-seven characters, cut down to a name meaning something else, or nothing. All
of them take sixty-three now, which is what the shell reads of a command line, so nothing
longer can arrive. Wander with it, since a directory is a path too.

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

Programs/CosmOS/Apps/More.asm

@@ -12,7 +12,7 @@
 
 start:
   SETD.0 Name
-  INIB 0d29
+  INIB 0d63
   SWI osArgument
   SETD.0 Name
   LDA.0
@@ -111,19 +111,23 @@ noName:
   SWI osPrintString
   INIA 0d2
   SWI osExit
+; ---- What went wrong, in words ----
+;
+; It used to print the number the filesystem answered with, as "error 2". THERE IS NO SUCH
+; VOCABULARY: the library documents its answer as zero or not zero and never as a code, so
+; the number named nothing and could not be looked up - it just looked like it could.
+;
+; A name that is not on the disk is the only way opening fails that a person can do anything
+; about, and it is nearly always a name typed slightly wrong. Saying so is more use than any
+; number would have been.
 openFailed:
   SETD.0 OpenError
   SWI osPrintString
-  BRI printError
+  BRI failed
 readFailed:
   SETD.0 ReadError
   SWI osPrintString
-printError:
-  RSTA
-  MVQB
-  SWI osPrintNumber
-  SETD.0 NewLine
-  SWI osPrintString
+failed:
   ; ITS OWN EXIT, and it did not have one. This fell through into finished and reported
   ; that everything was fine, having just printed the reason it was not - which nobody
   ; noticed while the only reader was a person, who could see both.
@@ -140,9 +144,11 @@ Usage:
 "more: give me a file name
 "
 OpenError:
-"more: cannot find the file, error "
+"more: there is no file by that name
+"
 ReadError:
-"more: cannot read the file, error "
+"more: the disk would not give me that file
+"
 NewLine:
   0x0A 0x00
 MorePrompt:
@@ -150,7 +156,7 @@ MorePrompt:
 ClearPrompt:
   0x0A 0x00
 Name:
-  #Reserve 0d29
+  #Reserve 0d64
 Remaining:
   0x00 0x00
 LinesLeft: