home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11628 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  3.5 KB

  1. Xref: sparky comp.lang.c++:11628 comp.editors:1830
  2. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!wupost!think.com!cayman!pgf
  3. From: pgf@cayman.COM (Paul Fox)
  4. Newsgroups: comp.lang.c++,comp.editors
  5. Subject: Re: Undoing, Emacs and unlimited files ... summery.
  6. Message-ID: <9261@cayman.COM>
  7. Date: 27 Jul 92 19:51:02 GMT
  8. References: <NMOUAWAD.92Jul27131847@math.waterloo.edu>
  9. Followup-To: comp.lang.c++
  10. Organization: Cayman Systems Inc., Cambridge Ma
  11. Lines: 63
  12.  
  13. nmouawad@waterloo.edu (Naji Mouawad) writes:
  14.     ... a nice summary of undo strategies in various editors
  15. :
  16.  
  17. Gee, if I'd known everyone was going to be so informative, I'd have replied
  18. to the original posting -- but better late than never:  since it's just a
  19. little different than the other method's described, here's how vile does
  20. undo:
  21.  
  22. (Note this is a vi-style "one command" undo, which undoes itself -- it is
  23. not an "infinite" undo.)
  24.  
  25. [ vile uses the linked list method of storage, with dynamically allocated
  26. text blocks hanging off of each line "header". ]
  27.  
  28. Undo operates by keeping a stack of "changed" lines (i.e.  those affected
  29. by a given command), along with information (more later) as to where they
  30. should go if an undo is actually required.  Thus if a character is deleted
  31. on a line, a copy of the original line is pushed on the undo stack.  If a
  32. line is deleted, is simply moved to the undo stack.  If a line is inserted,
  33. a "tag" is pushed on the undo stack, which tells us where the corresponding
  34. deletion should occur at undo time.  Only the first change to a line causes a
  35. copy to be stacked -- at that point, the line is flagged as having been
  36. copied already, suppressing further copies.  Since undo is itself undoable,
  37. I found it easiest to keep two undo stacks -- when we do an undo, the
  38. changes we are now undoing are simply put onto the alternate undo stack. 
  39. Multiple undo commands in a row simply cause us to move from one stack of
  40. changes to the other (rebuilding the other each time).
  41.  
  42. A certain amount of grottiness comes in because what we store as the
  43. information needed to put the lines back in their place are actually
  44. pointers to the lines in front and in back of its original location.  Since
  45. these pointers may be invalidated by subsequent changes during the same
  46. command (if, say, the line following a changed line goes away altogether),
  47. we need to store some pointer patches on the stack as weil, which, in
  48. essence, say "when you pop this, go down through the stack and change all
  49. instances of pointer A to pointer A', because that's its new value".  I
  50. didn't say it was beautiful.  I would probably do things differently if I
  51. were to do it now -- I knew _nothing_ about editors when I started
  52. converting micro-Emacs to vile.
  53.  
  54. One advantage of this stack approach is that it simply accumulates all
  55. changes to a buffer until told to clean up the stacks.  Thus it was trivial
  56. to make global operations (:g/str1/s/str2/str3") and macros (like a set of
  57. commands executed with '@a', or via the keyboard macro-recorder) undoable
  58. all at once.  The first case just worked, and for the second, I simply
  59. delay the stack cleanup if a macro replay is in progress.
  60.  
  61. Vi connosewers (sp? :-) will note that this is different than the stock vi
  62. approach, in that it is totally independent of the default yank buffer. 
  63. That is, doing an undo will not affect the contents of the yank buffer.  I
  64. consider this a feature.
  65.  
  66.  
  67. paul fox, pgf@cayman.com
  68.  
  69.  
  70. (yes, it's available for ftp -- at ftp.cayman.com:/pub/vile)
  71.  
  72. -- 
  73.         paul fox, pgf@cayman.com, (617)494-1999
  74.         Cayman Systems, 26 Landsdowne St., Cambridge, MA 02139
  75.