[comp.emacs] do-auto-save bug/feature

Ram-Ashwin@cs.yale.edu (Ashwin Ram) (02/16/89)

GNU Emacs 18.52.26 of Wed Feb 15 1989 on leo.ring.cs.yale.edu (Domain/OS)

Sometimes while auto-saving, I see the following message:

    Buffer <...> has shrunk a lot; not autosaving it

I consider this a bug since I would like my files to be auto-saved regardless
of whether Emacs thinks I have deleted too much stuff from them.  As long as
auto-save-mode is on, I consider the file valuable enough to be auto-saved.

Regardless of whether this is a bug or a feature, however, how do I turn it
off?

Thanks,

-- Ashwin.

ARPA:    Ram-Ashwin@cs.yale.edu
UUCP:    {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin
BITNET:  Ram@yalecs

skip@skipnyc.UUCP (Skip Gilbrech) (02/20/89)

In article <50852@yale-celray.yale.UUCP> Ram-Ashwin@cs.yale.edu (Ashwin Ram) writes:
>GNU Emacs 18.52.26 of Wed Feb 15 1989 on leo.ring.cs.yale.edu (Domain/OS)
>
>Sometimes while auto-saving, I see the following message:
>
>    Buffer <...> has shrunk a lot; not autosaving it
>
>I consider this a bug since I would like my files to be auto-saved regardless
>of whether Emacs thinks I have deleted too much stuff from them.  As long as
>auto-save-mode is on, I consider the file valuable enough to be auto-saved.
>
>Regardless of whether this is a bug or a feature, however, how do I turn it
>off?

You have to patch the source to shut this off.  I got so annoyed with this
'feature' that I did so a couple of weeks ago (this patch is for fileio.c
from GNU Emacs 18.52):

*** fileio.c~	Sat Aug 20 12:14:24 1988
--- fileio.c	Sun Feb 19 22:48:03 1989
***************
*** 1922,1927 ****
--- 1922,1931 ----
  	  && b->save_modified < b->text.modified
  	  && b->auto_save_modified < b->text.modified)
  	{
+ #if 0
+ 	    /* sg - it's a stupid assumption that the contents of a
+ 	     * shrunken file aren't worth saving...
+ 	     */
  	  if ((XFASTINT (b->save_length) * 10
  	       > (b->text.size1 + b->text.size2) * 13)
  	      /* These messages are frequent and annoying for `*mail*'.  */
***************
*** 1933,1938 ****
--- 1937,1943 ----
  	      Fsleep_for (make_number (1));
  	      continue;
  	    }
+ #endif	/* 0 */
  	  SetBfp (b);
  	  if (!auto_saved && NULL (nomsg))
  	    message1 ("Auto-saving...");
-- 
Skip Gilbrech                           UUCP: uunet!pwcmrd!skip
PaineWebber, NYC                              attmail!skipnyc!skip

kjones@talos.UUCP (Kyle Jones) (02/22/89)

In article <357@skipnyc.UUCP> skip@skipnyc.UUCP (Skip Gilbrech) writes:
>+ 	    /* sg - it's a stupid assumption that the contents of a
>+ 	     * shrunken file aren't worth saving...

Well, that's not quite the assumption that's being made.

The idea behind the 10/13th's Rule is that if a buffer is significantly
smaller since the last auto-save, then it is better not to overwrite the
auto-save file, since the auto-save file contains potentially valuable
data.  Very valueable indeed if you'd accidentally hit C-w sometime within
the last 300 keystrokes and killed more text than undo can recover.

The "Buffer %s has shrunk ..." message lets you know that your buffer has lost
a lot weight and gives you a chance to recover, before it's too late.

Folks who read gnu.emacs probably remember me arguing against this
feature.  I did so because I have never deleted a big chunk of my
buffer without realizing it.  But I can see how it COULD happen if,
say, I were touch typing in a document and not looking at the screen.
A novice could make a mistake like this even while looking at the
screen.  (Thanks, RMS, for prodding me to think a bit more.)

However, there are still problems.

1) The rule works OK for large buffers but is too sensitive to changes in
   buffers smaller than 3K.  Replying to news or mail with included text
   is a good example of this.
2) The rule can cause Emacs to refuse to auto-save a buffer that hasn't
   been auto-saved at all.  For example, the article I'm typing hasn't been
   auto-saved at all because I used 'F' from rn and then killed most of the
   included text before Emacs auto-saved.  Even if Emacs get sent a fatal
   signal, if the 10/13th's Rule says don't auto-save, it won't.
3) There ought to be a variable to turn this feature off.  I suspect we'll
   see this in v19.  Surely having the auto-save code recognize a buffer 
   named "*mail*" is a transient thing.

kyle jones   <kjones@talos.UUCP>   ...!uunet!talos!kjones
"You take romance, I'll take Jello."

julian@uhccux.uhcc.hawaii.edu (Julian Cowley) (02/23/89)

In article <443@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes
regarding the annoying "Buffer has shrunk; not saving it" message:
>However, there are still problems.
>
>1) The rule works OK for large buffers but is too sensitive to changes in
>   buffers smaller than 3K.  Replying to news or mail with included text
>   is a good example of this.
>2) The rule can cause Emacs to refuse to auto-save a buffer that hasn't
>   been auto-saved at all.  For example, the article I'm typing hasn't been
>   auto-saved at all because I used 'F' from rn and then killed most of the
>   included text before Emacs auto-saved.  Even if Emacs get sent a fatal
>   signal, if the 10/13th's Rule says don't auto-save, it won't.
>3) There ought to be a variable to turn this feature off.  I suspect we'll
>   see this in v19.  Surely having the auto-save code recognize a buffer 
>   named "*mail*" is a transient thing.

[I've already emailed a reply to Ashwin, but since there seems to
be general interest, I'll post a reply, too.]

Someone has already written a variable into Emacs to turn this
feature off, and the patch was posted to gnu.emacs.bug a little
more than a month ago.  Unfortunately the article has already
expired on this system and I never saved it, but I do have the
author's address: <mcvax!diku.dk!seindal@uunet.uu.net>.  Hope-
fully, version 19 will include this variable.  However, one
thing that is certain according to some email RMS sent me, is
that version 19's behavior will definitely be different from the
current: the message will turn auto-saving off in the buffer
until the user explicitly asks for it to be turned on again.

If the variable should exist in version 19, then (1) above could
be taken care of with a buffer hook if not any other way.  But
(2) above seems to me to be a bug; perhaps you ought to send a
bug report to gnu.emacs.bug (and at the same time put a plug in
for the variable (3), too :-).

julian@uhccux.uhcc.hawaii.edu
uunet!ucsd!nosc!uhccux!julian
julian@uhccux.bitnet
"People who aren't amused don't talk."