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

Previous Next

Full log

Message #29 received at 64439 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Michael Albinus <michael.albinus <at> gmx.de>
Cc: dhowells <at> redhat.com, 64439 <at> debbugs.gnu.org
Subject: Re: bug#64439: 28.2; auto-fill-mode gets turned on all over the place
Date: Mon, 10 Jul 2023 14:59:26 +0300

> Date: Sun, 9 Jul 2023 11:00:46 -0700
> Cc: dhowells <at> redhat.com, 64439 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.