Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)

[Guy Harris]

>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).