🚀 go-pugleaf

This issue is going to become more and more important as the UNIX Mac is
released.  Apple has committed themselves to preserving the Mac interface
while also supporting UNIX(tm).  But my gremlins (actually, experience with
the Mac Programmer's Workshop) report that they don't really have a complete
or general paradigm for doing this yet.  I'd like to see some discussions on
how this ought to be done.

Briefly, the problem is this.  On the Mac, all user applications are graphic
applications.  On UNIX, very few applications use graphics beyond those
attainable on a hardcopy character-graphics terminal.  While the flexibility
of the UNIX system for an expert programmer has never been approached by any
other operating system, it is notoriously unfriendly and mystifying to naive
users.  This is too bad, because many of its applications, such as grep,
would be very useful to any user at any level of experience.

Most bitmapped UNIX systems just ignore the problem and pretend that it is
sufficient to use bitmapped output devices to provide multi-window terminal
emulators.  The Mac shows that this is not true, that for user interfacing
every application should be a graphics application, that the presentation of
options to the user as controls and menu items achieves much more user
friendliness.  But this leaves open the issue of integrating the existing and
extremely high-quality UNIX system into the Mac's graphics-intensive
environment.

To make matters worse, it is impossible to just change the applications to
use a bitmapped user-friendly interface.  One of the great strengths of UNIX
is the ability to create multi-process programs, even on the fly, by using
pipes and i/o redirection to chain together multiple programs.  This is made
possible only because of the use of a character-stream, non-graphics
interface for most applications.  If this is lost, then no way is it UNIX.
But if it is retained as a user interface, no way is it either Mac-like or
novice-friendly.

To take a concrete example, the grep program provides an extremely useful
search facility.  On the Mac, it should be a dialog box allowing
specification of a range of files to search (using an extended standard file
interface) and a regular expression to search for, with help windows to
explain the use of regular expressions.  If this is the only interface, it
becomes impossible to use grep in multi-process programs.  So it would
appear that both interfaces need to be retained, but in different contexts;
and this is true not only of grep, but of most other applications as well.

There seem to me to be two basic options for solutions to this problem (or
to put it in the usual jargon, this is the top level of the decision tree).
First, we may modify the existing UNIX applications.  Second, we may make
some sort of separate input/output filter for each application.  In either
case, we need some way of detecting the type of the input, output, and error
channels, which may be tty (or pseudo-tty) windows, pipes, files in the file
system, or bitmapped i/o systems.  A simple ioctl will suffice for this
purpose.  In the first solution, the type checking is done by the
application itself; in the second, it is done by the "shell" (which would
presumably be something like Servant).

It seems cleaner to me to set up separate i/o filters, although this would
probably increase system overhead.  It is possible that some specification
language for such i/o filters could be created that would obviate the need
to write a C program for filtering and also not require that a separate
process run to mediate between the program and the user.  Hacking the UNIX
applications themselves seems like a much bigger job, and one that would be
likely to introduce new bugs into the applications, which at this point are
fairly well-tested and bug-free.

Any other ideas on this subject?
-- 
Tim Maroney, Electronic Village Idiot and Self-Assigner of Pretentious Titles
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)

"Little people, with tiny brains; little bullets flowing in their veins!
What do they want?  They want you!" - Oingo Boingo, "Tiny Guns"

In article <1091@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>
>Briefly, the problem is this.  On the Mac, all user applications are graphic
>applications.  On UNIX, very few applications use graphics beyond those
>attainable on a hardcopy character-graphics terminal.  
>
>To make matters worse, it is impossible to just change the applications to
>use a bitmapped user-friendly interface.  One of the great strengths of UNIX
>is the ability to create multi-process programs, even on the fly, by using
>pipes and i/o redirection to chain together multiple programs.  This is made
>possible only because of the use of a character-stream, non-graphics
>interface for most applications.  

There was a very interesting presentation at this year's Summer Usenix
on communicating data between processes in different windows existing
in a graphical user environment.  It was called "A Data-Flow Manager for
an Interactive Programming Environment", and was given by Paul Haeberli
of Silicon Graphics.  The accompanying paper may be found in your local
copy of the 1986 Summer Usenix Proceedings.  The system amounted to a
way to pipe data between graphical manipulation and display programs, and
provided a user-interface that made specifications of input and output 
sources easy (lines and arrows, etc.)
-- 
 Matt Landau      	 		BBN Laboratories, Inc.
    mlandau@diamond.bbn.com		10 Moulton Street, Cambridge MA 02238
 ...harvard!diamond.bbn.com!mlandau     (617) 497-2429

Tim Maroney raises some good points.  Before I plunge into substance,
I'd like to say something about user interfaces for the record.  [Please
note that this next paragraph expresses my *opinion*.  I am not trying
to force my views upon the world; I just want to express a contrary
opinion.]

I'm not sure that I agree that the Mac has "proven" that a menu-dialog
interface to all programs is best.  I would agree that such an
interface is easier for novice users; however, having to continually
move from the keyboard to the mouse and back again to do *anything*
on the Mac is one of the most worst features of its user-interface
for me.  I am far more productive with "vi" on UNIX than with any of
the mouse-based editors I've run across on the Mac.  Similarly, a
command-line interface (coupled with history and aliases) lets me get
my work done a lot quicker than a mouse-based interface.  I have no
use for things like "dbxtool" on the Sun -- I am considerably more
productive with the command-line interface.

User preferences vary, and I'm sure my opinion on them isn't shared
by everyone.  My point, however, is that it is not sufficient to choose
between a mouse interface and a dialog interface solely upon the type
of output device.  I would prefer a command-line interface even on a
bitmapped screen, and I suspect many other "power users" of UNIX would
also.

In addition to filters, the command-line interface to UNIX programs is
required for terminals connected by serial lines.  Bitmapped systems
are connected to standard terminals -- dialups in particular are quite
common.

So, I agree that the command-line interface to UNIX must be retained.
Now, what is the best method by which to add a visual interface?

I'd propose that a visual interface to UNIX be a separate program, not a
series of changes to individual programs.  This is consistent with the
treatment of pattern-matching in the shell -- it is performed in one place
rather than many.  It allows users to write their own visual shells.
[How many people have actually written their own command-line shell?]
It also allows a program written on one machine (e.g. a VAX) to be used
directly on (e.g.) a Macintosh.

It is unfortunate that the only interface to UNIX programs is the
untyped argv list.  At this late date, perhaps the best solution is
to define a program-interface file which specifies the names and
types of the arguments to a given program.  A visual shell would
read this file upon startup.  Programs not named would be invoked in
the traditional fashion.  (Doesn't someone's menu-based interface to
UNIX already work this way?)  When a new program is installed, the
system manager would add the interface definition to the appropriate
file.  (This could be automated as part of a "make install".)

What form should such an interface file take?  A Lisp (or Lisp-like)
definition would be the most flexible, but would presumably be more
difficult to write and might require a sizeable committment to Lisp
in the visual shell (making it large and perhaps too slow?).  A simpler
definition (perhaps expressed as a grammar with some attach semantic
information) might not be flexible enough.

We've actually discussed a lot of the issues in my group here at
LLNL because of the development of Amber (a Multics-like operating
system for our locally-designed machine).  If there is significant
interest in this topic, I'll see if I can dig up and summarize the
design decisions.  [Presently, the Amber command processor works on
cursor-addressible terminals, providing pop-up help menus, command-
filename-, and argument name-completion, and an EMACS-like line editor
for old command retrieval and editing.]
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor [jdb@s1-c.ARPA]	(415) 422-0758
  UUCP: ...!ucbvax!decwrl!mordor!jdb 	...!seismo!mordor!jdb

In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>  I am far more productive with "vi" on UNIX than with any of
>the mouse-based editors I've run across on the Mac. 

  Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha
Ha Ha Ha Ha Ha Ha Ha Ha Ha
Ha Ha Ha Ha Ha Ha Ha Ha Ha
Ha Ha Ha Ha Ha Ha Ha Ha Ha
Ha Ha Ha Ha Ha Ha Ha Ha Ha
     Considering my experiences with vi (holding the up/down/left/right keys
causes some versions to delete random snatches of text) this is the most 
hilarious thing i've ever heard. When I'm programming  the thing I do most
often is move around in the file. You cant tell me that pointing and clicking
with the mouse isn't faster then banging away on random cursor keys. It's true
that you can go directly to a specific line number but you can't easily go up
five lines and over twenty characters. Also a mouse based editor is much easier
to cut & paste in (which if you looked at code I've written  you'll know why
I like this--" Who needs a for next loop I'll just paste it in five times") 

     Also, you need to move your hands away from the "home row" whenever you 
hit the escape key or any other "control key". The mouse isn't any worse
( unless you have an infinate typing speed). However, there is one small
thing I should mention, I'm using a trackball instead of a mouse (desk space
Yay!!!!!!!). If you are using a mouse on a towel (yucky surface) I might
believe you but otherwise. Snicker Snicker...

Nuff Said

Pierce wetter

Pierce T. Wetter (...!tybalt.caltech.edu!wetter) writes:

> Ha Ha Ha Ha Ha Ha Ha Ha Ha
> Ha Ha Ha Ha Ha Ha Ha Ha Ha
> Ha Ha Ha Ha Ha Ha Ha Ha Ha

I think it's just this kind of discussion that John Bruner was trying
to avoid when he expressed a preference, with all the disclaimers that
he was expressing his opinion.  Although I myself would enjoy hearing
your (netwide) opinions on the subject of user interfaces, I wouldn't
want to read them hear.  It is enough to say, "The interfaces Foo,
Bar, Bletch-II, and even Bletch are popular, and will have to be
considered in this discussion.".  Discussions of their relative merits
is better held in, oh, probably net.cog-eng (or if there's a
talk.interface going...).

Just trying to nip a heated-argument-that-doesn't-belong-here in the bud,
Silver.

Silver (argyros (greek), argentum (latin))

  Silver is the whitest and most reflective of the metals, also having
  the highest thermal and electrical conductivity.  It is second only
  to gold in malleability and ductility.

  name: Andy Gaynor
  e-address: ...!topaz!gaynor
  address: 19 Evergreen Drive, Denville, 7 Raven Drive, Morristown
  phone: 627-8953, 267-8660

  atomic symbol: Ag       atomic number: 47  atomic weight: 107.88
  isotopes: 107 (0.5135), 109 (0.4865)       melting point: 950.5 C
  boiling point: 1950 C   density: 10.49     hardness: 2.5 - 3.0

In article <816@Diamond.BBN.COM> mlandau@slate.BBN.COM (Matt Landau) writes:
>
>There was a very interesting presentation at this year's Summer Usenix
>on communicating data between processes in different windows existing
>in a graphical user environment.  It was called "A Data-Flow Manager for
>an Interactive Programming Environment", and was given by Paul Haeberli
>of Silicon Graphics.  The accompanying paper may be found in your local
>copy of the 1986 Summer Usenix Proceedings.  The system amounted to a
>way to pipe data between graphical manipulation and display programs, and
>provided a user-interface that made specifications of input and output 
>sources easy (lines and arrows, etc.)

The great thing about this is that it allowed you to set up arbitrary
data-flow graphs, not just pipes.  This is important for interconnecting
3D graphics tools, since one program may have several "inputs".

What it does *not* do is allow you to set up a straight pipeline, the most
common form of parallelism in UNIX, as fast as just typing '|'.

One of the nice things about UNIX is the rapidity with which you can
put together "paste x y z | egrep pattern | sort | awk 'commands'".
To do this while staying in the MAC user interface model would require
that the shell be made into a graphics program, with some sort of
graphical way of building all of the constructs that you can currently do
with a command line.

Now, a graphical tool for building pipelines isn't too hard to imagine.
But the shell (any of them) is actually a quite powerful programming
language, and I find it hard to imagine a graphical tool with all the
flexibility of the shell (loops, conditionals, background processes,
argument processing) that would not be incredibly clumsy to use, just
because of all the possible choices.

So, a question:  If you had the best programming team in the world
available, able to implement any consistent design you came up with,
how *would* you design a shell?

In article <981@cit-vax.Caltech.Edu>, wetter@tybalt.caltech.edu.Caltech.Edu (Pierce T. Wetter) writes:
> In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
> >  I am far more productive with "vi" on UNIX than with any of
> >the mouse-based editors I've run across on the Mac. 
> 
>   Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha

I am in 100% agreement with this. In my opinion, vi is the *worst*
screen-oriented editor that I have ever had the misfortune of using.
I am always finding new "features" that I wasn't aware of. Unfortunately,
the new features I discover usually wipe out random pieces of text
in mysterious ways that are difficult to reverse.

It all comes of trying to make "ed" look like a screen editor. What
a kludge!

-- 
Glend.	I can call spirits from the vasty deep.
Hot.	Why, so can I, or so can any man; But will they come when you
	do call for them?    --  Henry IV Pt. I, III, i, 53

	Bill Jefferys  8-%
	Astronomy Dept, University of Texas, Austin TX 78712   (USnail)
	{allegra,ihnp4}!{ut-sally,noao}!utastro!bill	(UUCP)
	bill@astro.UTEXAS.EDU.				(Internet)

In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>
>User preferences vary, and I'm sure my opinion on them isn't shared
>by everyone.  My point, however, is that it is not sufficient to choose
>between a mouse interface and a dialog interface solely upon the type
>of output device.  I would prefer a command-line interface even on a
>bitmapped screen, and I suspect many other "power users" of UNIX would
>also.
>
The above point leads me to wonder about the use of the two
editors that come with the Mactintosh version of the Aztec C
compiler.

How many users of Aztec C (or any other Mac compiler that
offers the choice) use the vi-like Z editor or the
mouse-based Edit? 

I personally agree with John, that both options should be
retained -- regardless of the hardware. In fact, we at Geac
are designing a user interface that will have that very
property. We are trying to arrange it so that it is not
necessary to choose a priori which mode a user is operating
in, but allow the user to switch between input modes
depending on how easy each request is to express in each of
the modes.

Len
-- 
---------------------------------------------------------------------
Leonard Vanek                       phone (416) 475-0525
Geac Computers International
350 Steelcase Rd. West              USENET ... !utzoo!yetti!geac!len
Markham Ontario L3R 1B3
Canada

Note: My Usenet path is subject to change on short notice!

In article <981@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter) writes:
>In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>>  I am far more productive with "vi" on UNIX than with any of
>>the mouse-based editors I've run across on the Mac. 
>
>     Considering my experiences with vi (holding the up/down/left/right keys
>causes some versions to delete random snatches of text) this is the most 
>hilarious thing i've ever heard.

Which just goes to show that you haven't much experience with vi.

>You cant tell me that pointing and clicking with the mouse isn't faster
>then banging away on random cursor keys.

Actually, I can. Somewhere I've got a paper describing a study done on
editor interfaces, and it turns out that the fastest interface - in
general - is a foursome of arrow keys plus function keys. Second is an
emacs-like interface (vi wasn't in the study), and third is the mouse.
Finding the mouse seems to be the killer.

>It's true that you can go directly to a specific line number but you
>can't easily go up five lines and over twenty characters. Also a mouse
>based editor is much easier to cut & paste in (which if you looked at
>code I've written you'll know why I like this--" Who needs a for next
>loop I'll just paste it in five times")

Being an emacs user, the thing that I most like about the mouse
interface is the ability to bounce to text in another window without
worrying about changing windows. But this is why my Amiga emacs has 24
bindable mouse buttons; so I can get LOTS of mouse functionality when
I start using it. I move between the two modes regularly.

Of course, cut in paste with or without the mouse is equally hard: go
to one end, mark, go to the other end, cut. The only real difference
is the moving. It's easier to do all this with whatever my hands are
on, be it the mouse or the keyboard.

>     Also, you need to move your hands away from the "home row" whenever you 
>hit the escape key or any other "control key".

Hmm. Seems that the ESC key on my Sun is easily reachable by the ring
finger of my left hand. In fact, I hit the F1 key (caps lock) above it
so often that I set it up to be an ESC key also. Of course, I have big
hands.

	<mike

In article <981@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP 
(Pierce T. Wetter) comments on what John Bruner writes:
>In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>>  I am far more productive with "vi" on UNIX than with any of
>>the mouse-based editors I've run across on the Mac. 
>
>  Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha
>Ha Ha Ha Ha Ha Ha Ha Ha Ha

	I use "cat | cc -O " myself.
-- 
------------------------------------+-----------------------------------------+
| Michael Mc Namara                 |  MM MM MM    OO   SSS   AAA   II  CCCC  |
| ESL Incorporated                  |   M   M  M  O  O S         A   I C    C |
| ARPA: mac%esl.UUCP@ames.ARPA      |   M   M  M  O  O  SSS   AAAA   I C      |
|       mac%esl.UUCP@shasta.ARPA    |   M   M  M  O  O     S A   A   I C    C |
|       mac%esl.UUCP@lll-lcc.ARPA   |  MM   M  M   OO   SSS   AAA A III CCCC  |
------------------------------------+-----------------------------------------+
| Note: esl used to be called tflop; the path mac%tflop will still work awhile|
------------------------------------+-----------------------------------------+

In article <1091@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>This issue is going to become more and more important as the UNIX Mac is
>released.  Apple has committed themselves to preserving the Mac interface
>while also supporting UNIX(tm).  But my gremlins (actually, experience with
>the Mac Programmer's Workshop) report that they don't really have a complete
>or general paradigm for doing this yet.  I'd like to see some discussions on
>how this ought to be done.
>
>Briefly, the problem is this.  On the Mac, all user applications are graphic
>applications.  On UNIX, very few applications use graphics beyond those
>attainable on a hardcopy character-graphics terminal.

The problem is a difference in concept.  Unix creates a "stream of bytes"
which can be treated as a "stream of bytes" OR a "stream of objects".
In Unix, common objects include letters, words, lines, paragraphs, and
pages.  Applications of various "classes" such as find, sort, grep, and
awk, are actually subsets of the same type of record.  The important factor
here is that information that may be part of a larger set of classes, can
be extracted for use by smaller class operators.  C source can be "grepped"
for comments that can be manipulated by "awk" into information that can
be used by sort, join, lorder, find, and other "delimited field objects".

The Mac currently supports the concept of a "Stream of Objects", but objects
are often defined and remain unique to the application which creates them.
A "box" in MacProject may be quite different than a "box" in MacDraw or
MacPaint.  The clipboard and scrapbook are capable of supporting a subset
of these objects, but the ability to transform objects is not considered
mandatory to the application.

Such transforms are not impossible.  Other systems, which at least emulate
the Mac user interface, also define a standard set of objects, with the
capability for extensions.  Postscript has this capability as well.
VDI type interfaces are a key element.  A full VDI interface can take
"standard input" from a mouse/keyboard, or file, and display it to a
"bit-map screen", an "ACRTC device", a Laser Printer, or a disk file,
without knowing or caring which device is the output, or where the
output will go.

It may be possible to for example "grep" for "boxes containing text pattern",
but only if "boxes containing text pattern" are defined in a standard way,
such as group(box(x1,y1,x2,y2),text(x,y,string)).

Parsing of these groups and object streams requires an actual parser, but
should be possible, even simple to do.  A good test of such a parser would
be to output in "human-readable text form" any input file in "standard
stream of objects file", and have the "human readable form" become input
to a parser which will convert it back into "stream of objects" form.
Now you can put standard text filters, as well as "stream of object" filters
between the to resources.

Another concept that is important is that of "strings" as well as "packets".
Packets require that you know about certain information inside the packet
(such as number of objects, length in bytes,...) before the packet can
be sent.  Strings simply require an "end of string" delimiter.  A simple
object of this type could be added to the existing archetecture and
would enable creation of objects larger than the storage space available,
very important when only parts of a collection are needed.

>While the flexibility
>of the UNIX system for an expert programmer has never been approached by any
>other operating system, it is notoriously unfriendly and mystifying to naive
>users.  This is too bad, because many of its applications, such as grep,
>would be very useful to any user at any level of experience.

This is a valid point.  A few new products, such as Office-Power, GNU Emacs,
VSH, and a large assortment of other "visual shells" have made good progress
in this direction, but are most often limited by the weaknesses of the
"terminal interface" rather than the archetecture.  Building "classes"
of operators is more difficult, but not impossible.  The object oriented
design, rather than object oriented language, is all that is often needed.

>Most bitmapped UNIX systems just ignore the problem and pretend that it is
>sufficient to use bitmapped output devices to provide multi-window terminal
>emulators.  The Mac shows that this is not true, that for user interfacing
>every application should be a graphics application, that the presentation of
>options to the user as controls and menu items achieves much more user
>friendliness.

It is true, to a point, that each application should have a "graphics
interface" on the front end.  But it is also appropriate to have one
of the options be "text arguments", or function keys.  In addition,
the hierarchy of menus could be three dimensional, or even deeper.  For
example, the top line options might change as the various options are
scanned, allowing search of say 64 options using a simple 8x8 matrix,
of which only the options for the given menu selection are given.

>But this leaves open the issue of integrating the existing and
>extremely high-quality UNIX system into the Mac's graphics-intensive
>environment.

Try to think of it this way, the best part of UNIX is it's "back end"
or "application to application data compatibility".  The best part of
Mac (most of the time) is it's "front-end" intuitive graphics user interface.

>To make matters worse, it is impossible to just change the applications to
>use a bitmapped user-friendly interface.  One of the great strengths of UNIX
>is the ability to create multi-process programs, even on the fly, by using
>pipes and i/o redirection to chain together multiple programs.  This is made
>possible only because of the use of a character-stream, non-graphics
>interface for most applications.  If this is lost, then no way is it UNIX.
>But if it is retained as a user interface, no way is it either Mac-like or
>novice-friendly.

How about the ability to "draw circuits" of pipelines and filters for
"batch type jobs".  In fact, "tees" could get very interesting.  A "data
flow diagram" with prompts for each member of the circuit could also
be useful.  If input format and output format could be specified, it
might even be possible to normally restrict "next in chain" options
to those commands which create/use the appropriate format.  Of course,
it should be possible to enter text stream commands at some level as well.

As mentioned before, byte-streams and graphics DATA interfaces are not
necessarily mutually exclusive.  Conversely, character interfaces and
character streams are not necessarily mutually inclusive.  Try putting
a "pipe" between your standard input and VI if you need convincing.  A
"pipe" between VI and standard output might actually be useful (VI
would only need one definition of "termcap" and a "curses interface"
similar to those used by plot, could do the conversion to specific
terminal codes).  For editors, it might not be necessary to have
"streaming" capability, proprietary formats, during the actual editing,
might also have legitimate use (VI and various other interactive
editors put the proprietary format file in /tmp or /usr/tmp, often
under a process id type configuration.  The only special need is that
the final product be either saved or convertable to, a "standard data
interface format".

>To take a concrete example, the grep program provides an extremely useful
>search facility.  On the Mac, it should be a dialog box allowing
>specification of a range of files to search (using an extended standard file
>interface) and a regular expression to search for, with help windows to
>explain the use of regular expressions.

So far, not really a problem.  I can generate
'>grep 'object >' using either a text specification, or a visual interface
which creates the text specification.  If you wanted to be really perverse,
you could set up binary "argv, argc, and env", but that may be and extra
step.

>If this is the only interface, it
>becomes impossible to use grep in multi-process programs.

Only if you begin execution immediately.  Your "shell" parses for a complete
command in unix, your "Mac Shell" could wait until you pressed an "O.K."
dialogue box for the "Shell Command".  The command(s) which make up the
stream could be done as picture drawings, even with a "save" feature.
If you wanted to make it real interesting, you could "display" text mode
input versions.

>So it would
>appear that both interfaces need to be retained, but in different contexts;
>and this is true not only of grep, but of most other applications as well.

For matters of taste, this is true, but again, the two can compliment rather
than conflict with each other.

>There seem to me to be two basic options for solutions to this problem (or
>to put it in the usual jargon, this is the top level of the decision tree).

>First, we may modify the existing UNIX applications.

If you mean, modify the actual method "grep" uses for parsing it's arguments,
this may not be necessary.  In reality, you need a hybrid between the
"shell" and the "man" to create a visual shell that can create "standard
exec and popen" type calls for the shells.

>Second, we may make
>some sort of separate input/output filter for each application.

Again, transforming from one common form to another is not out of the question.
This however does not need to be done in each application.

>In either
>case, we need some way of detecting the type of the input, output, and error
>channels, which may be tty (or pseudo-tty) windows, pipes, files in the file
>system, or bitmapped i/o systems.

This is the "magical" feature of VDI.  What you will need is drivers which
use the standard "Virtual device" format, and transform tasks to convert
from one type to the other, hopefully in a "per object" mode.  Editors
should issue VDI calls directly (the same way they issue quickdraw calls,
but implementation of quickdraw calls rather than use of them become device
dependent.  In other words if you.

	fd1=fopen("window","w");
	fd2=fopen("diskfile",w);
	box(fd1,x,y,x2,y2);
	box(fd2,x,y,x2,y2);

the second box command might simply be a write of whatever the token for
"box" was and the binary co-ordinates.  So long as all applications agree
on one definition of "token for box", your all set.  Applications that
didn't use the standard set would have to provide the transforms to AND
from their proprietary format to at least one of the "general purpose"
formats.  Apple would be responsible for transforming from one "general
purpose" format to another.  For example "scrapbook to postscript" and
"postscript to scrapbook".

>A simple ioctl will suffice for this
>purpose.  In the first solution, the type checking is done by the
>application itself; in the second, it is done by the "shell" (which would
>presumably be something like Servant).

An important factor here is that the input type and output type of not
only the files, but also the applications must be available to the shell.

>It seems cleaner to me to set up separate i/o filters, although this would
>probably increase system overhead.

This is one option when two applications have incompatible formats.  In this
case it might be necessary to have two transform filters.  For example
MacDraw.Print GCCfile |MacDraw.to_scrap |MacWrite.from_scrap|MacWrite.grep|\
MacWrite.to_vdi|Laserwriter

Yes this is extra overhead, but it might not be necessary to do it often.
This might be used to extract a small portion of the file.  The important
thing here is that A) only a portion of the application needs to be running,
B) The user isn't required to remember where in the sequence he is when
he takes a break (with data stuck in the scrap).  He can also do something
else while waiting.

>It is possible that some specification
>language for such i/o filters could be created that would obviate the need
>to write a C program for filtering and also not require that a separate
>process run to mediate between the program and the user.

BINGO!!!  Apple already has three possible specifications, subsets and
supersets could be added, possibly even by the "install" of running and
application (sounds more like OS-9 all the time).

>Hacking the UNIX
>applications themselves seems like a much bigger job, and one that would be
>likely to introduce new bugs into the applications, which at this point are
>fairly well-tested and bug-free.

You may want super-graphics versions of certain types of filters, but
it is probably a good idea to keep the UNIX versions as-is.

One of the advantages of doing text-mode formats, is that humans are excellent
pattern recognisers.  They can often identify a pattern which would not
be obvious to the computer, the parser, or the user, when only binary
modes are available.

>Any other ideas on this subject?
>-- 
>Tim Maroney, Electronic Village Idiot and Self-Assigner of Pretentious Titles

There are a few, hopefully constructive ideas, for getting the best of BOTH
UNIX and MAC features, without giving up too much of either.

Rex Ballard.

In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>...  I would prefer a command-line interface even on a
>bitmapped screen, and I suspect many other "power users" of UNIX would
>also.

In article <137@geac.UUCP> len@geac.UUCP (Leonard Vanek) writes:
>The above point leads me to wonder about the use of the two editors that
>come with the Mactintosh version of the Aztec C compiler.
>
>I personally agree with John, that both options should be retained --
>regardless of the hardware.
>
>.. allow the user to switch between input modes depending on how easy
>each request is to express in each of the modes.

When using Aztec C, one may run a Mac program specifying arguments which must
be valid filenames (equivalent to selecting these files as icons together with
the application and then double-clicking).  Now, we could adapt mac programs
fairly painlessly to Unix by allowing any series of strings, not just filenames,
to be passed to applications.  Thus from the Unix side, Mac programs would be
fairly painless to use.

Now as for the Mac side, how do we pass strings to programs?  In the Finder/
Servant, perhaps one could click in the middle of whiteness, creating a text
item, a la MacDraw/MacPaint, and then select that along with the program
before double-clicking.

For pipes, they would use resources rather than straight text.  For Unix
programs, these would always be TEXT resources, but this need not be the case
for other programs.  Hopefully someone more intelligent than I might
think of a way to do this in a painless way so that no extra setup would be
required by the Unix programs like diff, grep etc. (ie no rewriting of code!)...

As for aliases/shell functions, there should be an artifact that would be
called a "Proxy Icon" that is basically a symbolic link to a real icon.  Then
these proxies and text items could be grouped and either put in a folder or
merged into a special icon that, when double-clicked (or perhaps command- or
option-double-clicked in the case of the folder) runs as if the text and the
given application were double-clicked.

A bit long-winded, but I hope you get the idea..  Please feel free to tell me
how foolish I am (preferable in reasonable terms :))
-- 
				"My surname is Li and my personal name is Kao,
				 and there is a slight flaw in my character."

Reid Ellis, aka
Clith de T'nir	{decvax,allegra,ihnp4,pyramid}!utzoo!utcs!yetti!unicus!rae
				or...	    seismo!mnetor!yetti!unicus!rae

>>> I am far more productive with "vi" on UNIX than with any of
>>> the mouse-based editors I've run across on the Mac. 

>> Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha

> I am in 100% agreement with this. In my opinion, vi is the *worst*
> screen-oriented editor that I have ever had the misfortune of using.
> I am always finding new "features" that I wasn't aware of. Unfortunately,
> the new features I discover usually wipe out random pieces of text
> in mysterious ways that are difficult to reverse.

My experience is different.  The new things I find out about periodically
are useful to me.  Vi is, for me, a productive editing environment, so
much so that I regularly write programs with it and then send the stuff
to my Mac for compiling and debugging.  And when I know I'm going to
make a lot of changes, I send it back to the Vax.

More general comment:
It's true that mouse-based editors make it easier to perform some of
the motion commands (e.g., 3 lines up, 20 characters left).  But isn't
it true that it's easier to perform other motion commands with
keystrokes (e.g., move to the top or bottom of the screen)?

Mac users (some of 'em, anyway) like to talk about modeless
operation, but let's not forget:  the mouse *IS* a mode.

Modelessness is a myth, propagated sometimes by people who should
know better.

-- 
Paul DuBois     UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois    |
                ARPA: dubois@easter                               --+--
                                                                    |
"If it works, I didn't write it."                                   |

In article <267@uwmacc.UUCP> dubois@uwmacc.UUCP (Bill Winkle) writes:
>Mac users (some of 'em, anyway) like to talk about modeless
>operation, but let's not forget:  the mouse *IS* a mode.

Actually the Mac mouse interface is highly modal.  The meaning of
a mouse click depends entirely on where you are on screen.  MS Chart
used to (still does? don't know) switch cursors every time the meaning
of a mouse-click changed.  Run that thing over a chart and the cursor
would change 5, 10, 15 times.

Edward Vielmetti, U-Mich Computing Center, ihnp4!umich!umix!emv
					   emv@umix.cc.umich.edu

In article <267@uwmacc.UUCP> dubois@uwmacc.UUCP (Paul DuBois) writes:
>Mac users (some of 'em, anyway) like to talk about modeless
>operation, but let's not forget:  the mouse *IS* a mode.
>
>Modelessness is a myth, propagated sometimes by people who should
>know better.

If I can figure out how to use vi, I'll reply.  I agree that modelessness
is a technically vague term.  It could be argued that even a text editor
like MacWrite has one mode, "obey-next-input mode".  But if a program has
one mode, it has no mode changes, and thus we call it modeless.  It is
also arguable that a font change command produces a mode, but so does a
caps lock key; I call either a "shift", which, as modes go, is innocuous
because the effect of forgetting which mode you are in is certainly less
drastic than that of typing "23d Street" without first entering insert
mode in vi.

Depending on how you choose to define "mode", the mouse could be called a
mode, but then so could the "7" key on a typewriter.  A useful definition
of mode is a state of a user interface that affects the interpretation of
subsequent inputs without obvious indication.  It is possible on the Macintosh,
using clover keys, to bring up a dialog box and thus enter a mode unknowingly.
But it is exceedingly rare compared with systems like vi that overload the
typing keys with functional meanings.

Let me add that, although I agree vi is an obnoxious editor, I do think it
deals with the mode problem gracefully.  Bad keystrokes often beep, undo is
always available for one command, and most vowels enter insert mode so it is
difficult to type a word as a command.

Modelessness is not a myth.  Like "seamlessness" or "painlessness", it is an
ideal that may rarely be attainable but is always worth approximating.  The
alternative is surely inhumane computing.

Larry Tesler, Advanced Development Group, Apple Computer, Inc.
The opinions expressed above are my own although I suspect more than a few
colleagues, not to mention users, would substantially agree with them.

In article <305@esl.UUCP> mac@esl.UUCP (Mike McNamara) writes:
>
>	I use "cat | cc -O " myself.

On what UNIXs does this work?   Most cc's that I have seen will not
take stdin.  To get the desired results, I have always had to do this:

	ln /dev/tty /dev/tty.c
	cc -O /dev/tty.c                # damn thing wants a ".c" file!
-- 
What's the difference between a duck?

Tim Smith       USENET: sdcrdcf!ism780c!tim   Compuserve: 72257,3706
		Delphi or GEnie: mnementh

In article <1091@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>This issue is going to become more and more important as the UNIX Mac is
>released.  Apple has committed themselves to preserving the Mac interface
>while also supporting UNIX(tm).  But my gremlins (actually, experience with
>
> [lots more good information here, but trimmed for brevity ].

Tim brings up good points on the problems of i/o re-direction on the
Mac.  It seems to me that most logical place to do this would be in
the stdio routines.  If we could change the stdio routines to do our
type checking, simply recompiling the program on the Mac would get it
running.  I may be missing the point, but it sounds like there are two
problems, one involving putting a Mac interface on grep (for example),
and one to do the actual i/o stuff.  As far as putting a Mac interface
on the program, I think that it would not be very hard to do for most
programs.  A subroutine at the beginning of the program which handles
the window stuff to set up the parameters, files, regexp's, etc., then
you pick something to start the program to actually "run" (for grep,
to start searching).  Two other things bother me, though.  One, how do
we tell a program to redirect its i/o in the first place, and two, how
do we handle all of the many different programs from Unix(tm)?  I
suppose that we could have some sort of menu that says "I want to run
some programs piped together", and then pick the programs in the
appropriate order, or we could do what was done for the Amiga in the
CLI interface (i.e. have something like a shell window where you use
the standard Unix syntax), and then let each program pop up a window
for it use.  For the second problem, Unix(tm) has the "path" concept,
but how do we do this on a Mac?  We don't want to have lots and lots
of program icons littering the desktop, and we really don't want to
have extremely long menus of commands.  Does this sound like a valid
problem, or am I just confused?
-- 
Mike Shaddock	{decvax,seismo,ihnp4akgua,philabs}!mcnc!rti-sel!shaddock

"You're in a twisty maze of sendmail rules, all obscure."

To add to the mouse vs vi editors debate, I will tell my story.

At work I use this nice SUN workstation, and I use the mouse only to
switch between screens, and evry so often, I will cut and paste with it.
I use only vi on this system (4.2) and I can quickly and easily produce
anything I need. 

At home I have an Apricot running MS-DOS and GEM. It takes average 4
hours to write and perfect a simple one page letter using its mouse
based editor. It takes forever to find anything in the letter, and
almost that long to move through the letter. I also hate having to move
my hand from the mouse to the keyboard continually.

I have NEVER had ANY experience with vi removing text and doing the
wierd things that the previous posters have stated, even when I was a
beginner with vi. It has ALWAYS been the best editor I have used. I
think the reason for this is that you can use whatever level of
expertice you want. If you are a begineer with it, you just have to know
how to insert, delete and save a file. With other editors I have tried
to use, you must know almost everything about it, just to get started.
Except of course for mouse based editors, which tell you nothing and
give the begineer no useful features.

Obviously, I have used the vi editor to write this followup, and I can
tell you that I had no problems doing so.

Brian Keves			ARPA:	keves%ra@sdcsvax.ucsd.edu
Lab for Math and Stats		UUCP:	sdcsvax!ra!keves
UCSD, La Jolla, CA	 	PHONE:	619-450-6421
Any opinions expressed are my own and are not the opinions of my employer.
-- 
Brian Keves			ARPA:	keves%ra@sdcsvax.ucsd.edu
Lab for Math and Stats		UUCP:	sdcsvax!ra!keves
UCSD, La Jolla, CA	 	PHONE:	619-450-6421
Any opinions expressed are my own and are not the opinions of my employer.

In article <137@geac.UUCP> len@geac.UUCP (Leonard Vanek) writes:
>In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>>
>>User preferences vary, and I'm sure my opinion on them isn't shared
>>by everyone.  My point, however, is that it is not sufficient to choose
>>between a mouse interface and a dialog interface solely upon the type
>>of output device.  I would prefer a command-line interface even on a
>>bitmapped screen, and I suspect many other "power users" of UNIX would
>>also.
>>
>The above point leads me to wonder about the use of the two
>editors that come with the Macintosh version of the Aztec C
>compiler.
>
>How many users of Aztec C (or any other Mac compiler that
>offers the choice) use the vi-like Z editor or the
>mouse-based Edit? 
>

I use the Z editor -- in fact, it's one of the reasons I bought
Aztec C.  Although I'm not entirely thrilled with vi, I'm used
to it and can live with it.  I haven't used Edit much at all but
I do use MacWrite regularly, mainly for correspondence but also
for memos.

Switching between mouse-based editing and a 'traditional' screen
editor has made me rather schizo.  It never fails that I'm in Z,
want to delete a large block of text, and reach for the mouse to
select the text.  Conversely, while in MacWrite I often enter
an (pseudo) ESC in an attempt to terminate text entry or try to
move backwards using 'b' or '-'.

I do like having the choice of environments, but I would like an
'integrated' (i.e., both pointer and command) environment even
better.  The examples I cited above illustrate the respective
strengths of each interface and suggest ways in which each could
be exploited to compensate for the weaknesses of the other.

I also like having the Aztec shell available on the Mac.  The
simultaneous menu and command-line interface is a simple example
of an integrated environment which is handy to use, especially
the compilation menu (does away with the need for compile/asm/link
scripts for simple programs).  The main problem with the Aztec shell
is that it's not really UNIX -- it can be quite frustrating not
being able to form pipelines, spin off background processes, etc.
Considering that it is a simple Bourne shell plus a number of
UNIX commands in a single program, however, it's pretty good.

Dave Bursik/..cbosgd!db

[]
>In article <305@esl.UUCP> mac@esl.UUCP (Mike McNamara) writes:
>>
>>	I use "cat | cc -O " myself.
>
>On what UNIXs does this work?   Most cc's that I have seen will not
>take stdin.  To get the desired results, I have always had to do this:
>
>	ln /dev/tty /dev/tty.c
>	cc -O /dev/tty.c                # damn thing wants a ".c" file!

Well, you guys are just wasting CPU time going through that compiler.
"adb /dev/mem"  is much more manly.

I'm rather surprised that no one has mentioned the AT&T 3b1 during this
discussion.  I realise that there are large differences between the
User Agent on the 3b1 and the Desktop on the Mac, but they look to be
related (disclaimer: I don't have any first-hand experience with the Mac).

Currently, it's possible to set up any single command on the 3b1 with the
User Agent & it's support of windows, using shform(1) if you want to do it
via a shell script, or menu(3t) & message(3t) if you want to handle it
via C code.  Using shform(1), for example, it's easy to set up a form
which requests all the info needed to run a grep (filename[s], pattern,
any additional options), which a shell script simply gives to grep.

In general, then, all you'd need is a program ala shform, which reads a
file containing a description of the desired user interface, interacts
with the user using the appropriate graphics interface, and returns the
results of said interactions in a form which a shell script can handle.

Any 3b1 gurus/developers care to comment?

Further disclaimer:  I have no relationship with AT&T other than being a
reasonably satisfied user of some of their computers, and no relationship
with Apple at all.
-- 
Rich Kuhns		{ihnp4, decvax, etc...}!pur-ee!pur-phy!mrstve!rjk

I seem to have started something that I had really hoped to avoid.  I'm
probably only making things worse by submitting this, but since the net
seems to be a medium devoid of restraint....

I am very dismayed at the general direction that this discussion has
taken -- whether or not "vi" is a good editor.  The line from my posting
which set off all of this discussion was:

> I am far more productive with "vi" on UNIX than with any of
> the mouse-based editors I've run across on the Mac.

This statement is true -- *I* like "vi" and *I* edit *very rapidly* with
it.  It does *not* say "Everyone would be far more productive with 'vi'",
nor does it even say "Everyone would be far more productive with a
keyboard-oriented editor".  I mentioned "vi" because it is the screen
editor that *I* use.  It was a concrete example which I cited only to
expand upon my general statement: *some* people prefer a keyboard
interface (for some tasks) to a mouse-based interface.

I cited other examples which noone seems to disagree with -- why didn't
someone ridicule me for preferring a command interface with history
and aliases to a mouse-based interface?  Perhaps this lack of response
resulted from my failure to mention specific programs which provoke
strong emotional responses in some people, although noone took me
to task for my preference for "dbx" over "dbxtool".

My sole objective in the paragraph containing the "vi" reference was
to state my belief, based upon my own personal experience, that
*some* users prefer a keyboard interface for *some* tasks to a
mouse-based interface (or worse yet, a hybrid interface that makes
one waste lots of time moving one's hands between the keyboard and the
mouse).  I realize now that I should have said "I am far more productive
with my *keyboard-based editor* on UNIX".  Of course, then there
probably would have been flames about "vi", every flavor of EMACS,
the Rand Editor, "ed", "qed", "ex", and who knows what else.

A mouse-based interface is appropriate for many situations and users.
I claimed that a keyboard-based alternative is appropriate for some.
That is all I said.  (I find some support for my opinion in the
existence of command-key equivalents on the Mac and their popularity
among so-called "power users.")

I am *not* knocking Apple's user interface guidelines.  I am *not*
suggesting that the *only* interface be a keyboard-only one.  I am
*only* suggesting that (at least for *some* things) *some* users
desire such an interface as an *alternative*.  Preferences for
user interfaces, like preferences for editors, vary, so I naturally
don't assume that everyone believes as I do.  Unfortunately, too often
it seems that advocates of mouse-based interfaces are not equally
willing to accept that other people may not agree that a mouse is
"the only way."

I do have some ideas on the original subject: adapting UNIX programs to
a Mac interface (both for transport to the Mac and for the implementation
of a Mac-like interface on top of UNIX), but as this posting is getting
rather long I'll put that material off until later.
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor [jdb@s1-c.ARPA]	(415) 422-0758
  UUCP: ...!ucbvax!decwrl!mordor!jdb 	...!seismo!mordor!jdb

In article <2866@sdcc6.ucsd.EDU> ir450@sdcc6.UUCP () writes:
>
>I have NEVER had ANY experience with vi removing text and doing the
>wierd things that the previous posters have stated, even when I was a
>beginner with vi. 

Methinks the folks complaining probably had a mismatch between their 
TERM setting and their terminal, or a corrupted termcap entry.  This 
can result in some *very* confusing screen displays.  The file, of 
course, is just fine; too bad you can't see what you're entering.

The sad choice between aztec Z (30% of vi, but 300 cps is *slow*)
and the mouse-based editors (faster display, but like plowing a field
with a hoe) is one I resolve by using either Z or using my own multi-window
editor, dumb virtue, soon to be shareware.  (Unfortunately this program
uses TE and is limited to 32K, bleah.  Had I but known how much trouble
TE would be when I started out, I might have tried writing my own TE.)

As for Mac/UNIX:  simplifying UNIX itself == bowdlerization.  I think
the graphics/human interface box should be functionally if not
physically separate from your UNIX CPU/disk server; communications
interfaces are getting fast enough to make this work real nice.  Thus,
you can write some nice visual interface code to hide the UNIX text
world commands without modifying UNIX itself; for those who want
unadorned (? overadorned ?) UNIX, it's lying in wait underneath.

How regular was my expression,
kevin

-- 
kevin eric saunders

ARPA: kevin@lasspvax   or   kevin%lasspvax.tn.gvax.edu@cu-arpa
UUCP: {ihnp4, allegra,...}!gvax!lasspvax!kevin

> To add to the mouse vs vi editors debate, I will tell my story.

Ditto.

> I have NEVER had ANY experience with vi removing text and doing the
> wierd things that the previous posters have stated, even when I was a
> beginner with vi. It has ALWAYS been the best editor I have used.

The problem here is that people are comparing apples and oranges.  

Everyone's using an editor called "vi".  Some satisfied users are using
it on dedicated workstations or local terminals on lightly loaded systems.
Some complainers are using it on dial-up lines or heavily loaded systems.

When I was in the latter group, I found the cursor keys virtually useless.
They send a series of characters, and vi rarely managed to buffer and
interpret the sequence correctly.  Sure enough, lines disappeared leaving
random garbage in their place.  

I've been in the former group, also (sort of): I've used Z, Manx's
vi look-alike on the Mac.  It's a 100% different experience.  If you like
keyboard-only editors, you'll love it.

So now will everybody shut up about this?

Larry Tesler writes in article 164@apple.UUCP

> In article <267@uwmacc.UUCP> dubois@uwmacc.UUCP (Paul DuBois) writes:
> >Mac users (some of 'em, anyway) like to talk about modeless
> >operation, but let's not forget:  the mouse *IS* a mode.
> >Modelessness is a myth, propagated sometimes by people who should
> >know better.

> If I can figure out how to use vi, I'll reply.  I agree that modelessness
> is a technically vague term.  It could be argued that even a text editor
> like MacWrite has one mode, "obey-next-input mode".  But if a program has
> one mode, it has no mode changes, and thus we call it modeless.  It is
> also arguable that a font change command produces a mode, but so does a
> caps lock key; I call either a "shift", which, as modes go, is innocuous
> because the effect of forgetting which mode you are in is certainly less
> drastic than that of typing "23d Street" without first entering insert
> mode in vi.
> 
> Depending on how you choose to define "mode", the mouse could be called a
> mode, but then so could the "7" key on a typewriter.  A useful definition
> of mode is a state of a user interface that affects the interpretation of
> subsequent inputs without obvious indication.  It is possible on the Macintosh,
> using clover keys, to bring up a dialog box and thus enter a mode unknowingly.
> But it is exceedingly rare compared with systems like vi that overload the
> typing keys with functional meanings.
> 
> Let me add that, although I agree vi is an obnoxious editor, I do think it
> deals with the mode problem gracefully.  Bad keystrokes often beep, undo is
> always available for one command, and most vowels enter insert mode so it is
> difficult to type a word as a command.
> 
> Modelessness is not a myth.  Like "seamlessness" or "painlessness", it is an
> ideal that may rarely be attainable but is always worth approximating.  The
> alternative is surely inhumane computing.

I don't really know whether modelessness is a myth or not, (though I 
suspect it is a myth).

For example, the dialog boxes and file selection boxes and pull-down
menus and click-drag mouse functions are ALL modes.

The idea is, however, to keep the modes simple and small, so that
a user's options and how to get at them are obvious.

So, MacWrite has lots of little modes, and vi has two big modes.

-----

bill idsardi
educational software products

.... utzoo!utcsri!utecfa!edusoft

In article <1279@jade.BERKELEY.EDU> mwm@eris.UUCP (Mike Meyer) writes:
>Actually, I can. Somewhere I've got a paper describing a study done on
>editor interfaces, and it turns out that the fastest interface - in
>general - is a foursome of arrow keys plus function keys. Second is an
>emacs-like interface (vi wasn't in the study), and third is the mouse.
>Finding the mouse seems to be the killer.
>

There was a paper entitled "The Evaluation of Text Editors: Methodology and
Empirical Results" by Teresa L. Roberts and Thomas P. Moran in the April
1983 Communications of the ACM.

This study compared 9 different editors (including Emacs, Teco, and several
Xerox mouse-based editors) using predicted and actual times to perform a
variety of tasks.  There were a couple of interesting things in the paper.

First, in their predicted times, they concluded that "the homing time
between the keyboard and pointing device is not a major problem".  The
exception to this was the WANG editor that relies heavily on function keys
separate from the main typing array.  

Second, in the actual timings with expert users the 2 fastest editors were
mouse-based, the third was the WANG.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET

> What's the difference between a duck?

One of his legs are both the same!  :-)

					Ed Morin
					Computer Resource Engineer
					Teltone, Inc.
					...uw-beaver!tikal[!colossus]!edm

Bill Idsardi writes in article 1897@utecfa.UUCP
> 
> I don't really know whether modelessness is a myth or not, (though I suspect
> it is a myth).
> 
> For example, the dialog boxes and file selection boxes and pull-down menus
> and click-drag mouse functions are ALL modes.
> 
> The idea is, however, to keep the modes simple and small, so that a user's
> options and how to get at them are obvious.
> 
> So, MacWrite has lots of little modes, and vi has two big modes.

Proving the myth of modelessness by picking at nits seems to be a waste of
time.  Larry Tesler gave a reasonable definition of the "modes" of which
people speak when they talk about modeless programming:

    A useful definition of mode is a state of a user interface that affects
    the interpretation of subsequent inputs without obvious indication.

The operant words here are "WITHOUT OBVIOUS INDICATION."  We can argue all
month about whether holding down the shift key or pushing the mouse button
while looking at a pull-down menu constitutes a mode in the strictest
definition, but all of this would be beside the point.  The idea behind
modeless programming is to eliminate surprises.

If I click-drag an object or pull down a menu, or hold down the shift key,
it is a conscious act for which I am getting direct feedback from the
system.  As a novice user of vi, I was constantly surprised by trying to
enter text, only to find that I was in command mode (with no obvious
indication).  That is the point.

One additional attribute of systems which are objectionably modal is their
way of navigating through the modes.  If holding the shift key is considered
a mode, it is not very objectionable because I can get out of it by just
letting go.  The same goes for pulldown menus.  If I don't like the choices,
I can intuitively avoid them by moving the cursor away before letting go.
Getting out of insert mode in vi, is not quite as easy, but can be easily
acquired through the learned behavior of hitting the ESC key.

The lesson here is NOT that systems should have no global states (i.e.,
modes) but that:

    o  Users should be able to know, without having to query, those states
	of the system that will affect what they are about to do.

    o  If in a state that the user no longer desires, they should be able to
	correctly guess how to get out of it (e.g., letting go of the shift
	key).

Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK

Larry Tesler:
> ....  A useful definition
> of mode is a state of a user interface that affects the interpretation of
> subsequent inputs without obvious indication.  It is possible on the Macintosh,
> using clover keys, to bring up a dialog box and thus enter a mode unknowingly.
> But it is exceedingly rare compared with systems like vi that overload the
> typing keys with functional meanings.

Although I enjoy the relative orthogonality of vi, I think that some
visible indication of whether one's input will be interpreted as text
or commands might be very desirable. But would it really be enough to
make vi "modeless"?
					Adam Reed (mtund!adam)

In article <1897@utecfa.UUCP> edusoft@utecfa.UUCP (BIll Idsardi) writes:
>The idea is, however, to keep the modes simple and small, so that
>a user's options and how to get at them are obvious.
>
>So, MacWrite has lots of little modes, and vi has two big modes.

I think the question is more to do with the "depth" of a mode, rather than its
complexity.  With MacWrite, "insert mode" is so shallow that you can't call it 
a mode - you can hit any of the shortcut keys as you type.  With vi, you must 
get out of exit mode before you can do anything but type more characters.

Anyway, I believe that one of the main determinants of a good user interface
is how easy it is to do something catastrophic.  With MacWrite (and most Mac
programs) it's hard; with vi (and most Unix programs?) it's easy.

In article <15530@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>
>A mouse-based interface is appropriate for many situations and users.
>I claimed that a keyboard-based alternative is appropriate for some.
>That is all I said.  (I find some support for my opinion in the
>existence of command-key equivalents on the Mac and their popularity
>among so-called "power users.")
>
I agree with you totally.  To support either one to the exclusion of the
other is a waste of time (at many levels:-).
  One of the joys of the mac user interface is it allows the novice and expert
to begin to operate effectively with no previous experience.  As you learn some
of the shortcuts you get to do the same things FASTER (having a larger 
and less obvious command vocabulary).
  At the novice level you can get around slower with your much limited 
vocabulary, but you CAN get around.
 I've run in to some who seem to believe that there is something WRONG with
command-key enhancement of the commonly percieved "mac interface".

 
----------------------
Ben Liberman

ihnp4!homebru!magik

"Whatever it was that I said...uh...I didn't mean it....honest !!!)

In article <981@cit-vax.Caltech.Edu>, wetter@tybalt.caltech.edu.Caltech.Edu (Pierce T. Wetter) writes:
> In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
> >  I am far more productive with "vi" on UNIX than with any of
> >the mouse-based editors I've run across on the Mac. 
[ deleted crap ( wasted space) ]
> with the mouse isn't faster then banging away on random cursor keys. It's true
> that you can go directly to a specific line number but you can't easily go up
> five lines and over twenty characters. Also a mouse based editor is much easier
Alright, try this : when in vi in the command mode enter: 5k20l 
See how fast that is! Your probably just to lazy to learn vi, it is inifinitely
flexible compared to any other editor. One must invest the time to learn!!!
I'll race you any day, and I'm not a touch typist. (boy will those people
be in trouble when Dvorak takes over, and it will)

> to cut & paste in (which if you looked at code I've written  you'll know why
> I like this--" Who needs a for next loop I'll just paste it in five times") 
> 
>      Also, you need to move your hands away from the "home row" whenever you 
> hit the escape key or any other "control key". The mouse isn't any worse
> ( unless you have an infinate typing speed). However, there is one small
> thing I should mention, I'm using a trackball instead of a mouse (desk space
> Yay!!!!!!!). If you are using a mouse on a towel (yucky surface) I might
> believe you but otherwise. Snicker Snicker...
> 
> Nuff Said
> 
> Pierce wetter
 
The above are the rantings of an deranged group of folks. not really ;-)

cy
{dj3b1,ihnp4}!killer!cy

"Degree,degree..... I don't need no stinking degree!!!"
Dangermouse is alive!!

In article <1066@batcomputer.TN.CORNELL.EDU> saunders@batcomputer.UUCP (kevin eric saunders) writes:
>>
>>I have NEVER had ANY experience with vi removing text and doing the
>>wierd things that the previous posters have stated, even when I was a
>>beginner with vi. 
>
>Methinks the folks complaining probably had a mismatch between their 
>TERM setting and their terminal, or a corrupted termcap entry.  This 
>can result in some *very* confusing screen displays.  The file, of 
>course, is just fine; too bad you can't see what you're entering.
>

The ones I have seen are often caused by terminals that send sequences
for function keys faster than the host can handle them.  The host misses
a character or two, and you end up with a random command.  This can
lead to a corrupt file.  It is a good thing vi has an UNDO command!

I have seen this happen on 68k unix boxes, and on a pc6300+.  I am
pretty sure I have also seen it on vaxes.
-- 
What's the difference between a duck?

Tim Smith       USENET: sdcrdcf!ism780c!tim   Compuserve: 72257,3706
		Delphi or GEnie: mnementh

Modes are okay.  Sometimes they seem quite appropriate.  For example,
I'm rather glad my automobile is moded (gas pedal takes effect when car
is running, different transmission gears for different cruising speeds,
headlights off when key not in ignition, and so on).  Modes seem like a
good way to deal with complexity in organization and function.

Please note that I am not saying (one way or another) whether a text
editor should be sufficiently complex to benefit by being moded.
--
Jim Valerio		tektronix!ogcvax!inteloa!jimv

In article <791@mtund.UUCP> adam@mtund.UUCP (Adam V. Reed) writes:
>Larry Tesler:
>> ....  A useful definition
>> of mode is a state of a user interface that affects the interpretation of
>> subsequent inputs without obvious indication........
>> But it is exceedingly rare compared with systems like vi that overload the
>> typing keys with functional meanings.
>Although I enjoy the relative orthogonality of vi, I think that some
>visible indication of whether one's input will be interpreted as text
>or commands might be very desirable. But would it really be enough to
>make vi "modeless"?

AT&T Version 3.9 of vi (comes with SVR2) has a "showmode" option which does just
that.  It's part of our standard options for novices.  I don't use it, partly
because of the wonderful things it does on paper terminals :-.  It helps a bit
when you forget which mode you're in.  Put "set showmode" in your $EXINIT.

Most emacs versions I've used have similar features, at least to the extent of
moving the cursor to line 24 during a ^X: command; when I use emacs I keep it in
Electric-C-Mode or nroff-mode (just to add fuel to the is-emacs-modeless fire.)

My reasons for using vi are more plebian; I learned it first and for most of
my work emacs isn't a big enough gain to switch.
-- 
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

> Your probably just to lazy to learn vi, it is inifinitely
> flexible compared to any other editor.

Allright,   try this for   a change: make  vi  behave like  Emacs,  my
favorite editor. We already know that Emacs can behave like vi  pretty
easily. Show that it goes the other way: that should be a good test of
flexibility.

The  persons whom I know  use vi look terribly  clumsy when  using it.
All those keystrokes! All that careful  thought about "How am I  going
to do this?"  And they've used it for more  than six  years!!  And the
work that they do to get effects that are easy to do in Emacs!!!

Show me that vi "is infinitely flexible compared to" Emacs.

--Mario

P.S. After your comment about  wasted space, why  did you include  the
rest of the other person's article in yours?

In article <585@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes:
>    A useful definition of mode is a state of a user interface that affects
>    the interpretation of subsequent inputs without obvious indication.
>
>The operant words here are "WITHOUT OBVIOUS INDICATION."  We can argue all
>month about whether holding down the shift key or pushing the mouse button
>while looking at a pull-down menu constitutes a mode in the strictest
>definition, but all of this would be beside the point.  The idea behind
>modeless programming is to eliminate surprises.
>
>If I click-drag an object or pull down a menu, or hold down the shift key,
>it is a conscious act for which I am getting direct feedback from the
>system.  As a novice user of vi, I was constantly surprised by trying to
>enter text, only to find that I was in command mode (with no obvious
>indication).  That is the point.

Sorry, Bob, I disagree.  Your version of vi (3.7) doesn't show you when
you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI
clone.  (It says "INPUT MODE" right there on the bottom line, or "I"
if you have terse set.  There are similar messages for r and R modes.)
In System V release 2, you can get this by putting "set showmode"
in your EXINIT, in release 3 it's on by default.

In spite of this, I still consider vi a moded editor, and I think most
others do too.  As an extreme example, ex command mode is certainly a
mode, with a very obvious visual indication (the : prompt and cursor
at the bottom of the screen.)

There's nothing wrong with being moded, it's just a personal preference.
I've taught vi to many novices, such as secretaries; I stick to a 10
command subset and they seem quite happy.

Mice and other pointing devices are handy for lots of things, but with
only two hands, you can't keep one hand on the mouse all the time.  A
really good mouse interface never has your hands on the keyboard, you
do everything with the mouse.  (MacPaint is a good example of this.)
But for a text editor, you can't reasonably input new text with a mouse,
and there's the problem.  There are so many things you want to do in a
complex text editor that you can't really put them all on a menu without
having zillions of menus and never being able to find anything.  This
goes for shell commands too.

A person who has learned a keyboard oriented editor like vi or emacs
becomes very familiar with that editor.  Commands become reflexive
habits, and switching to another editor is very painful; this is why
there are so many flames about editors.  I personally have the vi
command set hardwired in my fingers, so I'm not anxious to learn another
text editor or word processor.  It took a quantum leap in editor quality
to get people to switch from line editors to screen editors, and there
are still plenty of line editor users out there.  (My office mate hunts
and pecks at ed.)  It will take a similar quantum leap, plus near
universality of mice as standard input devices, plus a mousecap or
similar notion, to make people jump from screen editors to mouse editors.
So far I haven't seen the quantum leap, at best things seem about even.
(Cursor motion is easier but commands like "delete 2 sentences" or
"find the matching parenthesis", or even a simple search, are harder.)

	Mark Horton

> [Mark Horton]
> There's nothing wrong with being moded, it's just a personal preference.
> I've taught vi to many novices, such as secretaries; I stick to a 10
> command subset and they seem quite happy.

I face the problem of teaching vi to novices, also, and would be
interested to know what 10 commands you chose (and in hearing how
others handle this problem).
-- 
Paul DuBois     UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois    |
                ARPA: dubois@easter                               --+--
                      dubois@rhesus (no kidding)                    |
                                                                    |
"If it works, I didn't write it."
"That's for sure!"

In article <791@mtund.UUCP>, adam@mtund.UUCP (Adam V. Reed) writes:
>Larry Tesler:
>> ....  A useful definition
>> of mode is a state of a user interface that affects the interpretation of
>> subsequent inputs without obvious indication.  It is possible on the Macintosh,
>> using clover keys, to bring up a dialog box and thus enter a mode unknowingly.
>> But it is exceedingly rare compared with systems like vi that overload the
>> typing keys with functional meanings.
>Although I enjoy the relative orthogonality of vi, I think that some
>visible indication of whether one's input will be interpreted as text
>or commands might be very desirable. But would it really be enough to
>make vi "modeless"?
>					Adam Reed (mtund!adam)

:set showmode

('INPUT MODE' will show up on the status line when appropriate [if you have
also :set terse then there is just an 'I'])
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy

In article <2637@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes:
>
>Sorry, Bob, I disagree.  Your version of vi (3.7) doesn't show you when
>you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI
>clone.  (It says "INPUT MODE" right there on the bottom line,...

This change sounds like a definite improvement and one that I wouldn't
criticize without having a chance to see it, but an immediate concern of
mine would be how visible this indicator is for someone whose focus of
attention is the cursor, not the bottom of the screen.  I still might not
consider this indication as "obvious."

>There's nothing wrong with being moded, it's just a personal preference.

I agree that modes are useful and far be it from me to presume that either
vi or emacs be considered modeless.  My argument was not for the elimination
of modes, but for the elimination of modes which demonstrate the two
following features:

    o  Their presence is not obvious to the user (whatever this means in
	terms of visual or mechanical feedback).

    o  The mechanism for exiting them is not obvious.

There are features of both vi and emacs that arguably fall within these
dictates.  The criterion for "obviousness" is necessarily vague, because
level of expertise will affect the user's perceptions of natural behavior.
Knowing to hit ESC in vi is a learned behavior, just as is knowing to hit ^G
in emacs to abort multi-keystroke commands.  Neither is particularly obvious
if you don't know about them in advance.

>Mice and other pointing devices are handy for lots of things, but with
>only two hands, you can't keep one hand on the mouse all the time.
>
>...for a text editor, you can't reasonably input new text with a mouse,
>and there's the problem.

Agreed.  Despite the attractiveness of the "cut and paste" style text
editing paradigm, the actual mechanics of using such a system for text
editing are cumbersome.  That is not the same as saying that keyboard driven
editing and cut-and-paste editing cannot be used in concert.  Cut-and-paste
grafted onto emacs would be a definite wart, but a useful one.  


Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK

When I found out that vi 3.9 understood function keys and had
showmode (puts an I in the lower right corner when in insert
mode, R in Replace, r in replace), I thought "neato!" but after
using them for 5 minutes I got quite disgusted at the number of
bugs in the implementation:

	The mode indicator goes off if you auto-word-wrap on the last
	line of the screen.

	The mode indicator goes off if you use any function keys while
	in insert mode.

	You are kicked out of insert mode if you get a beep from a
	function key; e.g., if you use the arrows and hit the end
	of a line.

	If you press a function key while in Replace mode, you are
	put back into Input mode instead of Replace (of course the
	indicator has disappeared because of bug #2).

	Function keys are implemented from insert mode by simulating
	an ESC, doing the function, then simulating an "i" command.
	This means if you are in a "cw" command, the line gets scrunched
	when you press an arrow key, for instance.  Not exactly a bug,
	but it is surprising.  This causes very undesirable behaviour
	for some function keys, for example DELCHAR.  When you press
	DELCHAR in command mode, it executes the x command and deletes
	the character under the cursor.  Fair enough.  Now say you are
	in input mode.  When you hit DELCHAR, an ESC is simulated, so
	the cursor moves back one.  Then DELCHAR (x) is done, deleting
	the current char, and you are put back in input mode (i).  This
	has the net result of deleting the character IN FRONT OF the
	cursor.  Now try to explain this to a novice:

		The DELCHAR key deletes the current character in command
		mode, but it deletes the previous one in input mode.

	Sounds stupid, doesn't it?

The main problem with VI from a screen editor point of view is that it
is really a line-oriented screen editor:

	Forward and back word (b & w) go around lines, but forward and
	back character don't.  Also, forward word gets stuck at the end
	of a line if it ends with a space.

	Vi always wants the cursor to be on top of a character, instead
	of between characters, so you can't have a 0-length buffer, and
	empty lines look like lines with one space (the only easy way to tell
	them apart is to do an "x" on the line and see if it beeps).

	The newline character is a magic cookie.  I can't point the cursor
	to it, and I can't treat it like a normal character.  Therefore,
	because you can't "x" it, vi has another random command:  Join.
	This is the crux of the problem.

	You can't backspace around newlines in input mode.

	If you hit your line kill character in input mode, that line is
	gone forever.  It's sitting there in front of you, but you have
	to type it in again.

	In auto-indent mode, you have to type ^D to undent.  Why doesn't
	backspace work?

The other problem is that it is NOT a WYSIWYG editor:

	You type any change command (c,C,etc) and you get this
	funny $ at the end of the changed region and the $ and the
	text you changed aren't really there.  *Many* times I've had
	novices use the C command and hit spaces to the end of the line
	because they wanted to get rid of text that they didn't know
	was already "gone".

	This really makes it difficult to tell a new user what is
	going on.  You'd like to say "what's on the screen is what's
	in the buffer" but it just isn't true.

Also random inconsistencies that make it very difficult to make
blanket statements:

	The ]] command goes to the next line starting with {, but if
	you use "d]]" it deletes to the next line starting with }.
	I thought that the "d" command took a following motion command
	and deleted from the current position to where the motion would
	take me, but apparently not always.

I tried teaching VI to computer novices, but gave up because of the
non-WYSIWYG property and the constant confusion between input and
command mode.  (This was 3.7 vi on BSD, so there was no showmode.
Even if there were, it would have been too brain-damaged to use.)
I was constantly trying to explain things like the DELCHAR botch
or the $ stuff which makes absolutely no sense to the average user.
Then I got smart and typed up a short command list of the 30 most
common EMACS commands arranged by function, and the pleas for help
dropped off dramatically.
-- 
						Michael Baldwin
			(not the opinions of)	AT&T Bell Laboratories
						{at&t}!whuxl!mike

In article <2637@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes:
>In article <585@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes:
>>    A useful definition of mode is a state of a user interface that affects
>>    the interpretation of subsequent inputs without obvious indication.
>>
>>The operant words here are "WITHOUT OBVIOUS INDICATION."
...
>>As a novice user of vi, I was constantly surprised by trying to
>>enter text, only to find that I was in command mode (with no obvious
>>indication).  That is the point.
>
>Sorry, Bob, I disagree.  Your version of vi (3.7) doesn't show you when
>you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI
>clone.  (It says "INPUT MODE" right there on the bottom line, or "I"
>if you have terse set.  There are similar messages for r and R modes.)
...
>In spite of this, I still consider vi a moded editor, and I think most
>others do too.  As an extreme example, ex command mode is certainly a
>mode, with a very obvious visual indication (the : prompt and cursor
>at the bottom of the screen.)
>
>There's nothing wrong with being moded,

I think that we need to decide how "obvious" the indications must be
before one is willing to call something "modeless".  I don't consider a
word or two somewhere else on the screen, or a change in shape of the
cursor (as is common in many PC applications) obvious enough.  However,
moving the cursor out of the window, as is done for Emacs ESC-X commands
or Macintosh dialogs, is about as obvious as you can get without
grabbing the user by the collar and screaming "What extended command do
you want?" in his ear.

Emacs and MacWrite, however, are only modeless to a slightly greater
extent than vi.  Emacs has major (C, Lisp, Fundamental) and minor (Auto
Fill, Overwrite, Macro Learn) modes.  MacWrite has modes that specify
the justification, font, and style of the text to be typed in.  I think
that the difference between these and vi is the extent to which use of
the editor depends on the modes; a novice Emacs user might hardly ever
change modes, but a vi can't be used without going between insert,
overwrite, and edit modes relatively frequently.
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar

once you master an editor-interface well, you shouldn't have to waste your time
to learn another one - which isn't likely going to be a cost-effective move
anyway.  I am convinced that the same is true for learning natural languages
and consider the years I spent on Latin, Greek, French, etc. time that was
not spent in a very productive manner.  I approve of it for cultural and
humanistic reasons though and wished I could find the time to polish my
French again .....

In article <308@uwmacc.UUCP> dubois@uwmacc.UUCP (Paul DuBois) writes:
>> There's nothing wrong with being moded, it's just a personal preference.
>> I've taught vi to many novices, such as secretaries; I stick to a 10
>> command subset and they seem quite happy.
>
>I face the problem of teaching vi to novices, also, and would be
>interested to know what 10 commands you chose (and in hearing how
>others handle this problem).

Ok, here are the 10 commands I would teach someone :-)

	1.      rm /bin/vi              # adjust for local config.
	2.      ln /bin/qed /bin/vi
	3.      w
	4.      q
	5.      p
	6.      a
	7.      i
	8.      x
	9.      d
	10.     s

:-) :-) :-) :-) :-)
-- 
member, all HASA divisions              POELOD  ECBOMB
					--------------
					       ^-- Secret Satanic Message

Tim Smith       USENET: sdcrdcf!ism780c!tim   Compuserve: 72257,3706
		Delphi or GEnie: mnementh

In article <585@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes:
>    A useful definition of mode is a state of a user interface that affects
>    the interpretation of subsequent inputs without obvious indication.

I'll rewrite this:
	A mode is a system state.  The same user inputs in different
	modes get different system responses.
Or:
	Users input to systems.  Systems respond to users.  A mode is
	a set of pairs of user inputs and their corresponding system
	responses.  User inputs in the same mode get the same responses.
	User inputs in different modes may get different responses.

I'm aiming toward a definition that's sufficiently general to apply to a
variety of systems, devices, interfaces, and applications.  Whether and how
obviously a system indicates its mode is a testable matter.  If the user
behaves differently when the system indicates its mode, we can call the
indication obvious.  If the user behaves the same in the presence of an mode
indication as in its absence, then the indication wasn't obvious.  In fact,
as far as I'm concerned, in that case the system didn't indicate a mode.

I hope this kind of discussion is boring and dry enough to calm down the
vi versus mouse flames.  We're getting more heat than light.  It's more
useful to gain consensus on matters as basic as how to apply terms to
objects.  Hence I offer my use of the term "mode".  But actually I have
little interest in it, I'd rather see a useful definition of the terms:
	"sucessful user behavior"
	"effective use"
	"productive use"
and so on.  My definitions lack precision and vigor.  I'd have to say
something like "needs little reference to printed documentation or human
consultants" or "minimal time to first satisfactory result" or "user jumps
up and down and says he likes it" or "user rushes out and buys ten more of
it".  These are pretty imprecise, although demonstrably better than "I like
it and I think everyone should like it" or "it's just obviously better than
its competitors" or "what's wrong with it?  Everyone uses it here all the
time".

					-- jon

-- 
--> Jon Krueger
uucp: {seismo, bullwinkle, allegra, decvax, harvard}!rochester!ur-tut!tuba
Phone: (716) 275-2811 work, 235-1495 home	BITNET: TUBA@UORDBV
Drop in next time you're in the tri-planet area!

When I learned vi, and when I have to show someone how to use it,
I teach things in four segments:
		-Logging on and off, enough shell to create and delete
		 files and directories, entering and exiting from vi.
		-Entering draft text, a and i; a few basic macros;
		 Basic correction commands, moving in the file
		-Colon mode, strings
		-Printing to screen with formatter, copying and moving
		 files and parts of files, hard copy output and
		 calling macropackages.
Seems to work pretty well for most folks, because they can hold on
to things that are related in function, then move on to a new
part of the process.