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

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 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: bug#64439: 28.2; auto-fill-mode gets turned on all over the place
Date: Mon, 10 Jul 2023 09:00:14 -0700

On 7/10/2023 4:59 AM, Eli Zaretskii wrote:
>> 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>
>>
>> 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?

I'll add a 'local-variable-p' check to my test code, but whatever's 
happening here, it only makes 'auto-fill-function' non-local 
temporarily. Immediately after the backtrace I posted, I evaled 
"(setq-default auto-fill-function nil)" to fix the default value, and 
then called 'normal-mode' in a text-mode buffer, and it correctly 
enabled auto-fill-mode in just that buffer.

> 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.

That's true, though I'm pretty sure it's not the case here, since I 
noticed my prog-mode buffers suddenly have 'auto-fill-mode' (which 
prompted me to check my *Messages* output to get the backtrace. I'll add 
some extra checks here in my test code.

>> 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?

It's just a guess, but if some other Lisp code can run while Tramp is 
fetching the file data, that could possibly cause some issue.

Previous Next

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