From: "Marc VanHeyningen" <mvanheyn@spinner.cs.indiana.edu>
Subject: Re: More Defense of CLI  (there, I changed the subject ... )
X-Quoted: 53%
Reply-To: mvanheyn@whale.cs.indiana.edu
Organization: Computer Science Dept, Indiana University
Date: Sat, 10 Oct 1992 00:40:34 -0500

Thus said bcoleman@hayes.com (Bill Coleman):
>In article <1992Oct8.235008.14355@news.cs.indiana.edu>, mvanheyn@spinner.cs.indiana.edu (Marc VanHeyningen) writes:
>> Thus said bcoleman@hayes.com (Bill Coleman):
>>>Big deal. All it appears to do is save a bit of typing. Worse, it doesn't
>>>help you unless you know how many characters to type to get a unique name.
>> 
>> This is false.
>
>I was incorrect in my understanding, but my assertion still holds. (see below)

If you don't know how many characters to get a unique name, there are
two possibilities:

- You type too many.  No problem.
- You type too few.  The shell expands as many more as it can, beeps at
  you, and gives you the chance to add more.  Slight inconvenience.

In neither case does filename completion "not help you" at all.

>>>And what would happen if you had "Letter to Fred" as well as your
>>>"Letter to Bob". This completion stuff wouldn't help you at all.
>> 
>> Yes it would.  It would complete "Letter to ", as much as could be
>> completed unambiguously.  
>
>Ah! But that wasn't what you wanted. You wanted "Letter to Bob." You
>typed "LE<tab><return>" thinking that it would be unique. It wasn't. Uh
>Oh.
>
>This type of keystroke-saving "feature" is only useful if you have a
>perfect image of what is in the current directory in your head, and can
>compare the names to determine what is unique. Humans are notoriously
>bad at these tasks.

This is only a problem if you hit <RETURN> too fast, before receiving
the notice (often a beep) that the partial filename could not be
uniquely completed.  Any filename selection method can fail if you
make the assumption that the user will blindly accept things without
looking at them for even a nanosecond.

>> You could then bring up a list of "Bob" and "Fred" with another keystroke 
>> and type "B<tab>" to get it to work.  
>
>Oog. 

I'm sorry, that word is not in my vocabulary.  Is it some weird Mac term?

>> Have you ever even used filename completion in a shell?

>Yes I have. The one I helped design didn't require a charcter to do the
>matching. All matching was done continuously and instantaneously. (The way
>it should be)

I take that to mean "Yes, but it was totally unlike the system being
described."

>>>You shouldn't have to type ctrl-D. You should see the list automatically.
>> 
>> Just like on the Mac where you see the list automatically.  Well,
>> actually you need to open it up by double-clicking on it.  But double
>> clicking is much easier than typing control-D, at least by an order of
>> magnitude.
>
>Yup. Sometimes you don't need to open things up. For example, go into any
>Mac application bring up the standard get file dialog with File / Open. 
>You can type in a name there, or use the mouse on the list, or type,
>mouse and arrow keys in any combination.

For opening and manipulating just one file using just one application,
yes, this is probably usually superior.  As the old quote goes, GUIs do
make simple things simple.

>With a visual interface, typing is eliminated. So, features to reduce
>typing make no sense. Your original posting indicated that file name
>completion was a feature that CLIs had that visual interfaces do not. Feature
>counts don't necessarily help, since the feature not make sense in the other
>interface.

That was not my posting, that was someone else.  Not all people who
think there exist tasks for which existing CLIs are superior to the
Macintosh GUI are the same person, thank you.

I generally agree with you that filename completion is much less
applicable to a GUI than it is to something like tcsh, and that
selecting a single file is, for the average user, often easier in a
Macish way.

>In both user interfaces, attempts are being made to streamline the
>interface. If a visual interface requires lots of redundant pointing and
>clicking, I'd say it was defective -- it would appear to need methods to
>streamline use. 

So, how does one do composition of functions on a large number of input
files on a Mac without redundant pointing and clicking?
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted
Oh, so UNIX uses slashes for directory stuff!  Did they get that idea
from MS-DOS?  
		- <name withheld to prevent terminal embarassment>
Newsgroups: comp.sys.mac.advocacy