Subject: bug#21612: 24.5; Configuration variable to delete auto-save file when intentionally killing buffer

From: Eli Zaretskii <[email-masked]>
Date: Sun, 22 Aug 2021 12:29:41 +0300

> From: Lars Ingebrigtsen <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Fri, 20 Aug 2021 15:29:01 +0200
> 
> I actually tried this instead of making sense of the code, and:
> 
> emacs -Q /tmp/foo
> insert bar
> M-x do-auto-save
> M-x not-modified
> C-x k RET
> 
> The auto-save file is not deleted.
> 
> So I'm back to my second interpretation of the code -- I don't
> understand under what condition it's actually triggered (if any).

First, there seems to be an obvious logic bug there:

  /* Delete any auto-save file, if we saved it in this session.
     But not if the buffer is modified.  */
  if (STRINGP (BVAR (b, auto_save_file_name))
      && BUF_AUTOSAVE_MODIFF (b) != 0
      && BUF_SAVE_MODIFF (b) < BUF_AUTOSAVE_MODIFF (b)
      && BUF_SAVE_MODIFF (b) < BUF_MODIFF (b)  <<<<<<<<<<<<<<<<<<<<<<<<<<
      && NILP (Fsymbol_value (intern ("auto-save-visited-file-name"))))
    {
      Lisp_Object delete;
      delete = Fsymbol_value (intern ("delete-auto-save-files"));
      if (! NILP (delete))
	internal_delete_file (BVAR (b, auto_save_file_name));
    }

The condition I emphasized above should be reversed, because it means
the buffer _is_ modified, whereas according to the comment we need to
test that it _isn't_.  Right?

And second, I think the condition before it should be changed to say

      && BUF_SAVE_MODIFF (b) <= BUF_AUTOSAVE_MODIFF (b)

I see no reason to reject the situation where the two are equal.  Come
to think of this, I don't see why we need this last condition at all.
In its current form it means that the buffer was auto-saved since the
last save, but if it was auto-saved _before_ the last save, it means
the auto-save file is even less important to keep, right?  So maybe we
should remove that condition.

Adding Stefan, who considered this stuff 11 years ago.  Stefan, any
comments?

(There's also bug#5314 that's related to this.)