Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)
Message-ID: <1088@auspex.UUCP>
Date: 28 Feb 89 20:21:41 GMT
References: <25@torsqnt.UUCP> <225800127@uxe.cso.uiuc.edu> <7697@chinet.chi.il.us> <1016@auspex.UUCP> <7709@chinet.chi.il.us> <1023@auspex.UUCP> <7748@chinet.chi.il.us>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 23

>That's the real problem with human-engineered input styles - how
>do you represent something dynamic that is highlighted on the screen  
>in a command file, or even something like a key-up event?

Perhaps you don't do so directly.  Perhaps you have a "little language"
for "programming" the application, and a user interface that either sits
atop that "little language" or atop the same underlying mechanisms that
the "little language" sits atop.  Consider EMACS, for example; the
underlying "little language" (perhaps not so little...) is MockLISP or
ELISP, and the key-binding mechanism sits atop that.  Were I required to
drop down to the command line and type EMACS commands, or (Mock)LISP, in
order to get anything done, I'd be searching for a different editor.... 

The same could conceivably be done with non-keyboard input.  No, it
might not be convenient to "program" the application by typing the same
stuff you do at the keyboard into a file, and then just run the editor
with its input redirected to that file; given the choice between a user
interface like that, and a user interface that doesn't quite match what
you put into a "command file" but that lets me get the *interactive*
editing job done easier, I'd take the latter in a heartbeat (especially
given that a given session with the application may include *both*
interactive *and* "programmed" usage, so that redirecting the input to a
script may be the *wrong* answer).