Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!mintaka!ogicse!decwrl!shelby!csli!wilson
From: wilson@csli.Stanford.EDU (Nathan Wilson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW wish list
Message-ID: <12093@csli.Stanford.EDU>
Date: 6 Feb 90 00:41:46 GMT
References: <1990Jan23.065751.29303@peace.waikato.ac.nz> <6310@internal.Apple.COM> <3566@odin.SGI.COM> <10046@hoptoad.uucp> <3577@odin.SGI.COM>
Sender: wilson@csli.Stanford.EDU (Nathan Wilson)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 89

shap@delrey.sgi.com (Jonathan Shapiro) writes:

> The essential problems with the MPW editor are twofold.

> First, it constantly makes me remove my hands from the home position
> on the keyboard.  I am a computer-style touch typist (I type quickly,
> but not always accurately), and this reduces my effective throughput
> by at least a factor of five.
> ...

Actually, I've found the MPW editor to be only slightly less programmable
than Fred in Allegro Common Lisp or the gnuemacs editor.

Granted it isn't truely programmable, but if you're willing to deal with
a bit of gross syntax you can go a long way.

> I encourage you to attempt to add a keyboard shortcut for "backwards
> character" without the use of a macro facility (it can be done).  I
> encourage you to then try "page down", which can't be done even with a
> keyboard macro, and certainly can't be done with a shortcut.

In the MPW Shell it is trival:

addmenu Extras 'Back One' 'find <option>-6<option>-!1 {active}'

Adding a command equivalent for this is trivial.  I personally use
QuicKeys so I can bind the menu item to <control>-B.  For this case I
actually just bind <control>-B to left-arrow.  Anyway, with this and
a few similar hacks I can almost believe that I'm using emacs.  It
would be nice if I didn't have to use QuicKeys for changing the key
bindings but I can live with it.  If anybody's interested in my hacks
I would be happy to post them.

As for "page down", I haven't tried it but it shouldn't be all that
hard let's try:

addmenu Extras 'Next Page/<option>-v' <option>-d
'(evaluate "`sizewindow {active}`" =~ <option>-d
/<option>-x[0-9]+ ([0-9]+)<option>-r1<option>-x/) <option>-d
> dev:null ; <option>-d
(evaluate "`format {active}`" =~ <option>-d
/<option>-x-s ([0-9]+)<option>-r2 <option>-x/) <option>-d
> dev:null ; <option>-d
find !`evaluate {<option>-r1} div ({<option>-r2} + 2)`<option>-j {active}'

Hmm, seems to work pretty well for me.  By way of explanation:
The first line adds the menu, and menu item and gives it the command
equivalent <command><option>-v.  The second, third and fourth lines
extract the horizontal window size from the result of SizeWindow.  The
fifth line uses the horizontal window size to compute the number of
lines per page and then moves to the line on page below the current
selection.  You might be able to find a better way to compute the line
height than just adding a fudge factor (in this case 2) to the
{fontsize} but this is at least close.  Also you probably would want
to subtract the height scrollbar of the horizontal scrollbar from the
window height.  Actually this isn't 'true' next page since it goes from
the current selection rather than what is currently visible in the
window.  On the other hand, gnuemacs doesn't even make this distinction
to I think we can finesse it.  I can't find anything that gives you
the visible region rather than the selection region.  It seems that
these should be separately controllable from tools.

> How about "next-window"?

RTFM, unless you mean something other than RotateWindows.  You can also
get the back window to the front with:

(evaluate {windows} =~ /([<option>-l,]+)<option>-r1,<option>-x/) <option>-d
> dev:null ; <option>-d
open {<option>-r1}

> Indenting is most effective when interactive.  The ability to run a
> tool to indent things after the fact just doesn't give the right kind
> of support.

This seems more of a problem, but as I haven't needed anything weird
in this regard it hasn't bothered me.  I'm just thankful that it
doesn't impose an indenting discipline like LSP and I presume LSC.

> The editor should, if MPW is designed right, be a separate code
> resource(s), and should have a well-defined interface that could be
> implemented by an alternative.

I haven't hacked any tools so I don't know whether this is already
possible, but it seems that just some facility that allowed tools to
catch events would be all you would need.

Nathan Wilson
Teleos Research
nathan%teleos.com@ai.sri.com