bug#64439: 28.2; auto-fill-mode gets turned on all over the place

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 9 Jul 2023 11:00:46 -0700
> Cc: dhowells@redhat.com, 64439@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 7/8/2023 11:45 PM, Eli Zaretskii wrote:
> > I must be missing something: why is the above deemed to be a bug?
> > AFAIU, you asked any text-mode derivative mode to turn on auto-fill,
> > and this is what happened here: normal-mode called outline-mode, which
> > turned on auto-fill.  What am I missing?
> 
> The bug is that when this occurs, rather than setting 
> 'auto-fill-function' buffer-locally in text modes, it actually (somehow) 
> sets the default value of 'auto-fill-function'

I don't understand how this is possible with local variables.  Maybe
because some code calls makunbound for it?  Does local-variable-p
still return non-nil for auto-fill-function when this triggers?

Stefan, are there any other situations where setting a buffer-local
variable will actually set its default value?

Btw, it is possible that your trap snaps too late: that the default
value of auto-fill-function is non-nil does not yet mean this happens
when your hook is called, it could have happened earlier.  Because
setting the buffer-local value will DTRT regardless of the global
value, AFAIU.

> I've instrumented this code in a few other ways previously, and the best 
> I can guess so far is that at some point during this backtrace, Emacs 
> gets confused about the current buffer, so that when we ultimately call 
> "(setq auto-fill-function X)", the code to set the value buffer-locally 
> doesn't run.

As I say above, I don't understand how this can happen.  Even if we
are "confused" about the current buffer, at worst we will set
auto-fill-function in the wrong buffer.

> I've only ever seen this happen when 
> 'ask-user-about-supersession-threat' is in the stack. The backtraces 
> I've captured all include Tramp too, but I'm not sure the latter is 
> actually necessary to reproduce this bug, or if it just changes the 
> timings to make it more likely.

"Timings"? is this stuff asynchronous in some sense?  Michael, any
ideas?