🚀 go-pugleaf

   Spatial undo would undo changes in order of decreasing spatial
   proximity to point.

Great!!!   I often find myself wanting to undo some changes after
having done some more in other places of the file.  If just someone
knew how to implement this ...

		    Francesco Potorti`	| pot@cnuce.cnr.IT (Internet)
				 	| 39369::pot       (DECnet)
					| +39-50-593203    (voice)

In article <m0n9zZf-0001E5C@fly.cnuce.cnr.IT> pot@fly.cnuce.cnr.it (Francesco Potorti`) writes:

      Spatial undo would undo changes in order of decreasing spatial
      proximity to point.

   Great!!!   I often find myself wanting to undo some changes after
   having done some more in other places of the file.  If just someone
   knew how to implement this ...

Try apollo_tmlib_csm_src.tar.Z on on contrib at export.lcs.mit.edu.
The history object supports undo redo. 

The member functions of the history object as written enforce a protocol 
in which history of of undone operations is removed when a new operation
is recorded in history. But there are many other possible protocols that
could be handled through history::add_molecule().

The history object uses a circular buffer a certain size to record history;
this resembles the operation of the history command in UNIX. However, there
is a call to change the size of the circular buffer. Using this call
you should be able to expand the size of the array whenver it fills up.
This would allow you to retain history information about all operations
in a session.

There is a thornier problem with what you propose. If later operations were 
dependent on earlier operations that I have undone, what is the status or 
meaning of the later operations? If there are dependencies like this, 
probably the later operations are no longer valid after the undo of the 
previous operations. So I suggest either a rigorously modular
architecture for the operations (including lots of copying of data rather
than recording of a pointer argument) OR giving up the idea of saving the
history of the later operations once the earlier operations have been
undone.

One practical difficulty remains. The history object always "undoes" the
last recorded operation. It always "redoes" the last undone operation.
To do what you want there would have to be some capacity to browse the
history stack (with the eye or a program) so as to be able to choose
the appropriate operation to undo.

--
    John X. Laporta
    Technical Specialist
    jxl@opl.com
    TEL: (617) 965-0220 x 2579
    FAX: (617) 965-7599