home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / gnu / emacs / bug / 1629 < prev    next >
Encoding:
Text File  |  1993-01-11  |  2.5 KB  |  61 lines
  1. Newsgroups: gnu.emacs.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!opl.com!jxl
  3. From: jxl@opl.com (John X. Laporta)
  4. Subject: Re: suggestion for new emacs feature: spatial undo
  5. Message-ID: <JXL.93Jan11164152@ontario.opl.com>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: opl.com
  8. References: <9212231740.AA10850@life> 
  9. Distribution: gnu
  10. Date: Mon, 11 Jan 1993 21:41:52 GMT
  11. Approved: bug-gnu-emacs@prep.ai.mit.edu
  12. Lines: 47
  13.  
  14. In article <m0n9zZf-0001E5C@fly.cnuce.cnr.IT> pot@fly.cnuce.cnr.it (Francesco Potorti`) writes:
  15.  
  16.       Spatial undo would undo changes in order of decreasing spatial
  17.       proximity to point.
  18.  
  19.    Great!!!   I often find myself wanting to undo some changes after
  20.    having done some more in other places of the file.  If just someone
  21.    knew how to implement this ...
  22.  
  23. Try apollo_tmlib_csm_src.tar.Z on on contrib at export.lcs.mit.edu.
  24. The history object supports undo redo. 
  25.  
  26. The member functions of the history object as written enforce a protocol 
  27. in which history of of undone operations is removed when a new operation
  28. is recorded in history. But there are many other possible protocols that
  29. could be handled through history::add_molecule().
  30.  
  31. The history object uses a circular buffer a certain size to record history;
  32. this resembles the operation of the history command in UNIX. However, there
  33. is a call to change the size of the circular buffer. Using this call
  34. you should be able to expand the size of the array whenver it fills up.
  35. This would allow you to retain history information about all operations
  36. in a session.
  37.  
  38. There is a thornier problem with what you propose. If later operations were 
  39. dependent on earlier operations that I have undone, what is the status or 
  40. meaning of the later operations? If there are dependencies like this, 
  41. probably the later operations are no longer valid after the undo of the 
  42. previous operations. So I suggest either a rigorously modular
  43. architecture for the operations (including lots of copying of data rather
  44. than recording of a pointer argument) OR giving up the idea of saving the
  45. history of the later operations once the earlier operations have been
  46. undone.
  47.  
  48. One practical difficulty remains. The history object always "undoes" the
  49. last recorded operation. It always "redoes" the last undone operation.
  50. To do what you want there would have to be some capacity to browse the
  51. history stack (with the eye or a program) so as to be able to choose
  52. the appropriate operation to undo.
  53.  
  54. --
  55.     John X. Laporta
  56.     Technical Specialist
  57.     jxl@opl.com
  58.     TEL: (617) 965-0220 x 2579
  59.     FAX: (617) 965-7599
  60.  
  61.