Xref: utzoo comp.sys.amiga:37507 comp.sys.amiga.tech:6353
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!usc!apple!well!xanthian
From: xanthian@well.UUCP (Kent Paul Dolan)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: My AmigaDOS 1.4 wishlist (one among thousands!)
Summary: When you wish upon a checkmark ...
Keywords: list, dir, pipe:, loadwb, docs, rad1:, locks, selection, huge disks
Message-ID: <12878@well.UUCP>
Date: 27 Jul 89 20:40:52 GMT
Reply-To: xanthian@well.UUCP (Kent Paul Dolan)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 94

I've heard "it's in there" about the 1.4 release.  Here are my entries in
the great 1.4 wish list sweepstakes, in hopes that this is timely, and
finds some you missed.

Most important: make sure that the hard disk and other file system control
software is compatible with SCSI, removable medium, 1.5 Gbyte disks.  These
drives should arrive before the 1.4 release.  (Mfgr's name available to
CATS on request, if you haven't already had a demo of the existing
prototype.) In particular, limitations of "partition" sizes, numbers of
files/directories per directory node, maximum length of a path name, etc.,
should all be reviewed and improved in anticipation of truely fast, huge
(and extremely cheap; ~ $1/Mbyte drive cost) storage systems.  In most
cases, hard limits should be replaced by soft limits; path name arrays ->
path name c-strings, directory name arrays -> directory name link lists,
und so weiter.  I can hardly wait to put my 400 floppy disksfull of PD
software and data on one huge disk, and, at last, sort it out.  [Naturally
the only practical backup for such a beast is another one just like it, so
I'll probably buy two!]

Merge list and dir commands ("ls" would be a catchy name for the result!)
and add the capabilities (as an "option") to create a directory listing
with full path names of files and also one with file path names from the
current/selected directory, compatible with the "all" option.  This would
save half an hour per instance using an editor on "dir opt a" output to
prepare structured file name input for the "zoo aI" command, and similar
tasks.  The existing list command's LFORMAT option could do this if list
had dir's "all" option and the path names of subordinate directories were
added to the first %S output. 

Improve the list command LFORMAT option by using %P and %F for path and
file names instead of the current ambiguous (and therefore order dependent)
%S for both, and by allowing arbitrary numbers and orders of them in the
lformat string. 

Smarten up the dir command to put the maximum possible number of columns of
file names, depending on the longest name in each column plus a bit of
spacing, rather than a fixed two columns.  Even now, the workbench C: dir
overflows a screen in two column mode, so I use a PD routine called "ld"
for most directories, sacrificing alphabetized directories for four columns
of file names to have them all on one screen.  This would work best if the
directory titles were full path names from the starting directory, so that
indentation to show depth could be avoided.

Automatic processing of the output of "dir opt a" output is made more
difficult because there is no directory line given before the files in the
current/requested directory are listed.  Even '"" (dir)' would be a big
help.

Replace/supplement the existing "Pipe:" device with a real Unix(tm)-like
"|" pipe that can be used in a one line command.

Add a command to display/kill locks, to help clean things up when a disk
icon won't go away because some careless programmer left a lock engaged. 

Add a capability to use extended selection for _any_ program, without
change to the object module, to make it think it is getting command line
input.  I added a tool icon to my favorite microemacs (the one from
BENCHMARK Modula 2) and a project icon to files I was editing, but extended
selection won't convince the editor that it is seeing an argv[] character
string array containing a file name as argv[1].  It should be simple enough
to do this, and it would sure be nice to be able to do my work on "the
great American novel" in "point and shoot" mode, with long descriptive
project names tied to icons, rather than keeping a cli around and reverting
to short, quick to type file names.

While I'm on the subject, add paragraph flowing capability (preferably
including a fixed "indentation string" option, like GNUEmacs has) to the
Extras 1.3 MEmacs.  That would make it almost usable for text processing
tasks on simple ASCII files, since it already works in extended selection
mode.

An otherwise empty, INSTALLed disk with :s/startup-sequence = "loadwb"
and :loadwb version 1.3 its only files fails to boot with a return code 20
from loadwb.  The 1.3 docs for loadwb do not give any preconditions for its
successful operation, and none of the commands' docs give return code
interpretations.  Both these problems need fixing.  [I was trying to make
the Hack_Game: disk bootable, but it needed a workbench loaded to be
useful.  No joy.]

Generically, your command documentation needs much more motivational
information added.  When I read your docs, I know _how_ to use the commands,
but neither _why_, _when_, nor _where_.

Permit more than one RAD: (RAD0:, RAD1:, etc:) to be mounted, so that I can
copy several disks to memory, and give each the name its software is
expecting.  Possibly this could be best accomplished by adding a "name" (or
"as") keyword to the MOUNT command: "Mount RAD0: as HACK_GAME:" or "Mount
RAD1: name HACK_GAME" are examples (note the colon for "as" but not for
"name"). 

Thanks for listening, as usual.

well!xanthian
Kent, the man from xanth, now just another echo from The Well.