Re: the undo option

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Wed, 18 Nov 1998 09:24:30 -0800, Dov Isaacs <isaacs@Adobe.COM> wrote:

>To keep things in some perspective ...

We each have our own, y'know?  I'm always interested to hear yours;
you've given the list more valuable information and insights than
practically anyone else, and I respect you for that.  In this case,
our perspectives are real different...

>Lest anyone think otherwise, I don't think that anybody at Adobe would
>argue that such a feature as "unlimited undo" would be great and wonderful.

You mean "wouldn't", right?  <g>  As written, you seem to be saying
that *nobody* at Adobe thinks unlimited undo is a good idea, which I
doubt you really meant...

>It is also true that implementation of "unlimited undo" is not conceptually
>difficult ESPECIALLY IF YOU ENGINEER IT THAT WAY FROM THE BEGINNING. At the
>time that FrameMaker was originally written, the undo feature was not yet 
>"in vogue" and there was no competitive product that had it. Your cute
>characterization of the lack of a full unlimited undo feature as a "bug"
>represents a very nice case of Monday morning quarterbacking. 

Had I brought it up right after Word introduced it (in Word 4.0?), you'd
have a point.  But when it's been out for the vast majority of Windows
products for many years, including the tools Frame's developers use, it's
a legitimate characterization.  Yesterday's missing features become today's
bugs, simply as a result of age.  IMO.

>You are right
>in that this feature is conceptually not rocket science. But, FrameMaker is
>not rewritten with every release. Retrofitting that much code with a new 
>global feature is not as trivial as you would like to think. Claiming that
>you could personally do it "in a day at the very most" demonstrates that you
>really don't understand the nature of what would need to really be implemented!

Excuse me, Dov!  I was writing software when Frame's original author was
in grammar school!  I wrote the very first screen-oriented editor under
CP/M 1.4!  I think I know a bit about this field that I've spent the last
twenty years in.  And I even know a bit about how Frame is designed, as
exposed in the FDK.  I stand by my assertion.  There is no need to rewrite
Frame for this, sheesh!  It is a very "bound" problem, easily solved in the
Fcode interpreter.  I could write an FDK app that would do most of it, but
you'd be killed by the overhead of the notifications to the FDK DLL.  It
needs to be in the core interpreter to work efficiently.  And it should be.

>The devil is really in the details, not in the theoretical model of storing
>a script of operators in memory or otherwise. 

You miss my point entirely.  With its single-level undo, Frame has *already*
done the hard part, by encoding the actions required to undo a command.  Now
all you need to do is store the packet you already wrote in a stack, instead
of overwriting it each time.  That's it!  Sure, you could enhance it from
there, coalescing/decoalescing text insert/delete being a good candidate,
but just keeping a stack alone would be a vast improvement, for a first cut.
You don't even need Word's drop-down list that lets you go back many steps
in one shot; just the basics would make lots of people very, very happy.

>You cannot assume that on 
>"unrolling changes" that the environment is static. The code must assume 
>that available fonts and other system resource objects, imported and 
>referenced files, OLE links, available memory and disk resources, etc. may
>be different at "rollback time" than earlier in time on the same system
>when the operations first occurred. 

This argument applies equally to single undo as to multiple undo.  You
don't know from one second to the next that the externals you cite are
still the same.  Fortunately, for almost all cases, you don't care.  You
*do* know state *within* you own application, or else you've got a real
big problem... <bg>  If you are trying to say that some operations may
not be undoable at all, that is true only in very limited cases.  You
mention "OLE links", for example; sounds like you need the cooperation
of another app, right?  Wrong; the OLE info in the Frame file can be
deleted, then restored *as a chunk*, without involving the OLE server
in any way.  You confuse the map with the territory.  Undo/redo is a
totally internal operation, even when it acts on objects that are used
with external resources.

>When a "problem" occurs, you can either
>(a) crash, (b) issue an obscure error code, (c) issue an informative message
>but not really help the user, or (d) provide context-sensitive choices to
>the user. Personally, as a user, I would demand (d) which is clearly not
>a simple feature and I would demand that it really work, not just in the
>simple cases where nothing goes wrong. Compound this with the cross-platform
>nature of the beast. Taking all these possible error conditions into account,
>the REAL work required for the coding, testing, and debugging nature of this
>feature is tremendous!

What you have described here is the situation with *any* program problem,
with *any* feature.  Lord knows, we've all seen plenty of (a), (b), and (c)
with Frame, mostly (a) and (b) in the 5.5.x series... :-(  We've been asking
for (d) for a long time now.  But still, of all the features I can imagine
adding to Frame, making undo multiple-level is the *least* likely to have
any repercussions, as it involves only the **return to a known valid state**.
You can't get much safer than that, and still be executing code at all... ;-)

I really have trouble understanding why you are drawing this particular
line in the sand.  It would be a big win for Adobe to give Frame users an
enhancement they've wanted so long, that is so easy to implement... why
not just build it?  Pretty please?  <vbg>

-- Jeremy H. Griffith, at Omni Systems Inc.
   (jeremy@omsys.com)     http://www.omsys.com/
** To subscribe to Free Framers, email the message **
** body "subscribe framers" to majordomo@omsys.com **

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **