home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / gnu / emacs / bug / 1501 < prev    next >
Encoding:
Text File  |  1992-11-20  |  1.3 KB  |  35 lines
  1. Newsgroups: gnu.emacs.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!osf.ORG!macrakis
  3. From: macrakis@osf.ORG (Stavros Macrakis)
  4. Subject: autosave of large buffers
  5. Message-ID: <9211201710.AA17685@lakatos.osf.org>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: GNUs Not Usenet
  8. Distribution: gnu
  9. Date: Fri, 20 Nov 1992 07:10:44 GMT
  10. Approved: bug-gnu-emacs@prep.ai.mit.edu
  11. Lines: 22
  12.  
  13. Epoch 4.0.1 of Tue Jul 21 1992 on phoenix (aix-v3) (Emacs 18.58)
  14.  
  15. File operations can be very time-consuming on large buffers, both
  16. because of the I/O cost and because the whole buffer needs to be
  17. swapped in.  This is psychologically acceptable when you explicitly
  18. save a buffer, but is very annoying when it is an autosave (especially
  19. an autosave on the large buffer while you're working on a small
  20. buffer!).  It's especially annoying when the change to the large
  21. buffer was accidental (yes, I know I should use C-x C-r
  22. (find-file-read-only) instead of C-x C-f (find-file)....).
  23.  
  24. Incremental saves would be far cheaper, and Emacs already has the
  25. information to do them, in the form of undo data.  So why not save the
  26. undo data instead?  (except for buffers backed up by copying)  To
  27. protect against file deletion, a #-link could be made to the base
  28. file.  Of course, there is still the danger of the file being modified
  29. in place by someone else.
  30.  
  31.     -s
  32.  
  33.  
  34.  
  35.