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

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

[David Howells]

Hi,

I'm seeing an issue in which auto-fill-mode gets turned on for all the buffers
in a running emacs instance, including the command entry window (M-x, grep,
compile, etc.).  This is a problem as it starts mangling the code I'm working
on and making it harder to enter long commands (such as grep or compile
commands).  I can turn it off manually on most buffers (though not the command
window), but it immediately turns back on in a buffer if I have to reload it.

The problem has happened in several emacs instances now.  It shows up in the
instances I've been using to edit C code and view patches.  It takes a little
while for the problem to manifest when it does.  I'm not sure what triggers
it.

It doesn't, however, happen in the emacs instances I've been using to read my
mail with MH and edit occasional text files on the same system.

In both cases, the emacs instances are typically running for multiple weeks
till I need to reboot - or the issue becomes sufficiently irritating that I
restart emacs.

Thanks,
David


In GNU Emacs 28.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.37, cairo version 1.17.8)
 of 2023-05-02 built on 0cdeb17096554a4c83d448c2d2754877
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 39 (Rawhide Prerelease)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
 --program-prefix= --disable-dependency-tracking --prefix=/usr
 --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
 --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
 --with-dbus --with-gif --with-jpeg --with-png --with-rsvg --with-tiff
 --with-xpm --with-x-toolkit=gtk3 --with-gpm=no --with-xwidgets --with-modules
 --with-harfbuzz --with-cairo --with-json --with-native-compilation
 build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu CC=gcc
 'CFLAGS=-DMAIL_USE_LOCKF -O2 -flto=auto -ffat-lto-objects -fexceptions -g
 -grecord-gcc-switches -pipe -Wall -Werror=format-security
 -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11
XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Diff

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  indent-tabs-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message puny dired dired-loaddefs rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs
auth-source eieio eieio-core eieio-loaddefs password-cache json map mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils face-remap
make-mode help-fns radix-tree cl-print debug backtrace find-func conf-mode
vc-annotate vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs add-log
log-view pcvs-util vc rect smerge-mode diff pulse color rmc etags fileloop
generator xref project hippie-exp misearch multi-isearch shell pcomplete
thingatpt files-x grep compile text-property-search comint ansi-color ring
time-date jka-compr vc-git vc-dispatcher cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs comp comp-cstr warnings
subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv cl-loaddefs cl-lib
bytecomp byte-compile cconv diff-mode easy-mmode time iso-transl tooltip eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj
charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev
obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads xwidget-internal
dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process native-compile
emacs)

Memory information:
((conses 16 858994 53275)
 (symbols 48 17882 0)
 (strings 32 99037 4596)
 (string-bytes 1 5475389)
 (vectors 16 30928)
 (vector-slots 8 670739 45813)
 (floats 8 146 348)
 (intervals 56 136420 2641)
 (buffers 992 115))

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

[Eli Zaretskii]

> Cc: dhowells@redhat.com
> From: David Howells <dhowells@redhat.com>
> Date: Mon, 03 Jul 2023 16:55:05 +0100
> 
> I'm seeing an issue in which auto-fill-mode gets turned on for all the buffers
> in a running emacs instance, including the command entry window (M-x, grep,
> compile, etc.).  This is a problem as it starts mangling the code I'm working
> on and making it harder to enter long commands (such as grep or compile
> commands).  I can turn it off manually on most buffers (though not the command
> window), but it immediately turns back on in a buffer if I have to reload it.
> 
> The problem has happened in several emacs instances now.  It shows up in the
> instances I've been using to edit C code and view patches.  It takes a little
> while for the problem to manifest when it does.  I'm not sure what triggers
> it.

Try evaluating this:

  (defun my-watcher (_symbol new-value operation where)
    (error "auto-fill-mode: %s %s %s" new-value operation where))
  (add-variable-watcher 'auto-fill-function 'my-watcher)
  (debug-on-entry 'my-watcher)

and run your sessions with this.  Whenever auto-fill-mode is turned
on, you will get a backtrace.  If you turn this mode yourself, and
don't want to be annoyed by entering the debugger each time, remove
the last line from the recipe: then you will just see a message when
auto-fill-mode is turned on, and will need to investigate which code
did that.

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

[David Howells]

Eli Zaretskii <eliz@gnu.org> wrote:

> Try evaluating this:
> 
>   (defun my-watcher (_symbol new-value operation where)
>     (error "auto-fill-mode: %s %s %s" new-value operation where))
>   (add-variable-watcher 'auto-fill-function 'my-watcher)
>   (debug-on-entry 'my-watcher)
> 
> and run your sessions with this.  Whenever auto-fill-mode is turned
> on, you will get a backtrace.

I restarted emacs and added the above.  I was editing some C code, pressed
enter and got:

	Debugger entered--entering a function:
	* my-watcher(auto-fill-function nil set nil)
	  newline(nil 1)
	  funcall-interactively(newline nil 1)
	  command-execute(newline)

auto-fill-mode didn't seem to turn on, though - I'm not sure if that's to be
expected.  It's also not the first time I pressed enter in that buffer.

David

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

[Eli Zaretskii]

> From: David Howells <dhowells@redhat.com>
> Cc: dhowells@redhat.com, 64439@debbugs.gnu.org
> Date: Mon, 03 Jul 2023 18:48:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Try evaluating this:
> > 
> >   (defun my-watcher (_symbol new-value operation where)
> >     (error "auto-fill-mode: %s %s %s" new-value operation where))
> >   (add-variable-watcher 'auto-fill-function 'my-watcher)
> >   (debug-on-entry 'my-watcher)
> > 
> > and run your sessions with this.  Whenever auto-fill-mode is turned
> > on, you will get a backtrace.
> 
> I restarted emacs and added the above.  I was editing some C code, pressed
> enter and got:
> 
> 	Debugger entered--entering a function:
> 	* my-watcher(auto-fill-function nil set nil)
> 	  newline(nil 1)
> 	  funcall-interactively(newline nil 1)
> 	  command-execute(newline)

Hmm...

> auto-fill-mode didn't seem to turn on, though

Because the function newline only let-binds auto-fill-function
locally.

I guess tracking down this problem will be harder, then.  I hope I at
least gave you some ideas with which you will be able to construct a
suitable trap and find the culprit.  Good luck!

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

[Jim Porter]

On 7/3/2023 11:29 AM, Eli Zaretskii wrote:
> I guess tracking down this problem will be harder, then.  I hope I at
> least gave you some ideas with which you will be able to construct a
> suitable trap and find the culprit.  Good luck!

I got a backtrace when this happened to me. Outside of Emacs, I checked 
out a different Git branch, and then went back to Emacs and started 
typing into "etc/NEWS" (the specific file probably doesn't matter much), 
which triggered the supersession prompt as you'd expect. This was all 
over Tramp/SSH (again, not sure this is relevant).

Here's the debug code I added to trace this:

----------------------------------------

(use-package text-mode
   :preface
   (defun user/turn-on-auto-fill ()
     "Turn on auto-fill, but log a warning if it's not local to a buffer."
     (turn-on-auto-fill)
     (when (default-value 'auto-fill-function)
       (display-warning 'auto-fill :error
                        "Default value of `auto-fill-function' was set!")
       (backtrace)))

   :hook (text-mode . user/turn-on-auto-fill))

----------------------------------------

And here's the backtrace (plus a couple lines immediately preceding):

----------------------------------------

NEWS changed on disk; really edit the buffer? (y, n, r or C-h) r
Tramp: Inserting ‘/sshx:jim@remote:/home/jim/src/emacs/etc/NEWS’...done
   backtrace()
   (progn (display-warning 'auto-fill :error "Default value of 
`auto-fill-function' was set!") (backtrace))
   (if (default-value 'auto-fill-function) (progn (display-warning 
'auto-fill :error "Default value of `auto-fill-function' was set!") 
(backtrace)))
   (when (default-value 'auto-fill-function) (display-warning 'auto-fill 
:error "Default value of `auto-fill-function' was set!") (backtrace))
   user/turn-on-auto-fill()
   run-hooks(change-major-mode-after-body-hook text-mode-hook 
outline-mode-hook)
   apply(run-hooks (change-major-mode-after-body-hook text-mode-hook 
outline-mode-hook))
   run-mode-hooks(outline-mode-hook)
   outline-mode()
   set-auto-mode-0(outline-mode nil)
   set-auto-mode()
   normal-mode(t)
   after-find-file(nil nil t nil nil)
   revert-buffer--default(nil t)
   revert-buffer(nil t)
 
ask-user-about-supersession-threat("/sshx:jim@remote:~/src/emacs/etc/NEWS")
   tramp-handle-lock-file("/sshx:jim@remote:~/src/emacs/etc/NEWS")
   apply(tramp-handle-lock-file "/sshx:jim@remote:~/src/emacs/etc/NEWS")
   tramp-sh-file-name-handler(lock-file 
"/sshx:jim@remote:~/src/emacs/etc/NEWS")
   apply(tramp-sh-file-name-handler lock-file 
"/sshx:jim@remote:~/src/emacs/etc/NEWS")
   tramp-file-name-handler(lock-file 
"/sshx:jim@remote:~/src/emacs/etc/NEWS")
   newline(nil 1)
   funcall-interactively(newline nil 1)
   command-execute(newline)

----------------------------------------

This might not be the most useful backtrace in the world, but hopefully 
it at least confirms one way this can happen. It's rare enough though 
that I can't reproduce it on command. It does lead me to believe that 
there's a bug with automatically-buffer-local variables, since 
'turn-on-auto-fill' should Just Work here (and it typically does).

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

[Eli Zaretskii]

> Date: Sat, 8 Jul 2023 22:57:12 -0700
> Cc: 64439@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 7/3/2023 11:29 AM, Eli Zaretskii wrote:
> > I guess tracking down this problem will be harder, then.  I hope I at
> > least gave you some ideas with which you will be able to construct a
> > suitable trap and find the culprit.  Good luck!
> 
> I got a backtrace when this happened to me. Outside of Emacs, I checked 
> out a different Git branch, and then went back to Emacs and started 
> typing into "etc/NEWS" (the specific file probably doesn't matter much), 
> which triggered the supersession prompt as you'd expect. This was all 
> over Tramp/SSH (again, not sure this is relevant).
> 
> Here's the debug code I added to trace this:
> 
> ----------------------------------------
> 
> (use-package text-mode
>    :preface
>    (defun user/turn-on-auto-fill ()
>      "Turn on auto-fill, but log a warning if it's not local to a buffer."
>      (turn-on-auto-fill)
>      (when (default-value 'auto-fill-function)
>        (display-warning 'auto-fill :error
>                         "Default value of `auto-fill-function' was set!")
>        (backtrace)))
> 
>    :hook (text-mode . user/turn-on-auto-fill))
> 
> ----------------------------------------
> 
> And here's the backtrace (plus a couple lines immediately preceding):
> 
> ----------------------------------------
> 
> NEWS changed on disk; really edit the buffer? (y, n, r or C-h) r
> Tramp: Inserting ‘/sshx:jim@remote:/home/jim/src/emacs/etc/NEWS’...done
>    backtrace()
>    (progn (display-warning 'auto-fill :error "Default value of 
> `auto-fill-function' was set!") (backtrace))
>    (if (default-value 'auto-fill-function) (progn (display-warning 
> 'auto-fill :error "Default value of `auto-fill-function' was set!") 
> (backtrace)))
>    (when (default-value 'auto-fill-function) (display-warning 'auto-fill 
> :error "Default value of `auto-fill-function' was set!") (backtrace))
>    user/turn-on-auto-fill()
>    run-hooks(change-major-mode-after-body-hook text-mode-hook 
> outline-mode-hook)
>    apply(run-hooks (change-major-mode-after-body-hook text-mode-hook 
> outline-mode-hook))
>    run-mode-hooks(outline-mode-hook)
>    outline-mode()
>    set-auto-mode-0(outline-mode nil)
>    set-auto-mode()
>    normal-mode(t)
>    after-find-file(nil nil t nil nil)
>    revert-buffer--default(nil t)
>    revert-buffer(nil t)
>  
> ask-user-about-supersession-threat("/sshx:jim@remote:~/src/emacs/etc/NEWS")
>    tramp-handle-lock-file("/sshx:jim@remote:~/src/emacs/etc/NEWS")
>    apply(tramp-handle-lock-file "/sshx:jim@remote:~/src/emacs/etc/NEWS")
>    tramp-sh-file-name-handler(lock-file 
> "/sshx:jim@remote:~/src/emacs/etc/NEWS")
>    apply(tramp-sh-file-name-handler lock-file 
> "/sshx:jim@remote:~/src/emacs/etc/NEWS")
>    tramp-file-name-handler(lock-file 
> "/sshx:jim@remote:~/src/emacs/etc/NEWS")
>    newline(nil 1)
>    funcall-interactively(newline nil 1)
>    command-execute(newline)
> 
> ----------------------------------------
> 
> This might not be the most useful backtrace in the world, but hopefully 
> it at least confirms one way this can happen. It's rare enough though 
> that I can't reproduce it on command. It does lead me to believe that 
> there's a bug with automatically-buffer-local variables, since 
> 'turn-on-auto-fill' should Just Work here (and it typically does).

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?

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

[Jim Porter]

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', so *every* buffer has 
'auto-fill-mode' enabled.

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.

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.

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

[Eli Zaretskii]

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

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

[Jim Porter]

On 7/10/2023 4:59 AM, Eli Zaretskii wrote:
>> Date: Sun, 9 Jul 2023 11:00:46 -0700
>> Cc: dhowells@redhat.com, 64439@debbugs.gnu.org
>> From: Jim Porter <jporterbugs@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.

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

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

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

Sure, there timers, process filters, process sentinels, dbus
handlers, file notification handlers, you name it.

But my guess is that you're fighting with connection-local
variables. They do manipulate buffer-local variables.

Best regards, Michael.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[ Adding Noam, because this seems related to
  https://github.com/joaotavora/yasnippet/issues/919.  ]

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

Depends what you mean, but if you do:

    (let ((auto-fill-function #'foo))
      [...]
      (setq auto-fill-function #'bar)
      [...])

then `auto-fill-function` will not be made buffer-local.  But that won't
set the toplevel default value either (that default value will be
reverted to nil when we leave the `let`).

Interactions between buffer-local values and let-bindings can be tricky,
tho, so there might still be bugs in there.

Jim, did you collect various backtraces?  Do you still have them?
Can you check more thoroughly to try and see what they all have in common
(in addition to `ask-user-about-supersession-threat` and "Tramp")?

Can you get an interactive backtrace buffer?  If so, I'd be curious to
know the values that

    e (list auto-fill-function (default-value 'auto-fill-function)) RET

returns and more importantly, how it varies from frame to frame.


        Stefan

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

[Jim Porter]

On 7/10/2023 10:28 AM, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Jim, did you collect various backtraces?  Do you still have them?
> Can you check more thoroughly to try and see what they all have in common
> (in addition to `ask-user-about-supersession-threat` and "Tramp")?

Unfortunately no. I set this issue aside previously, since I was having 
a hard time making progress. I'll try to keep them around going forward 
though.

> Can you get an interactive backtrace buffer?  If so, I'd be curious to
> know the values that
> 
>      e (list auto-fill-function (default-value 'auto-fill-function)) RET
> 
> returns and more importantly, how it varies from frame to frame.

Will do. The next time I hit my (updated) debug code, it'll drop into 
the debugger and I'll try to get some info out of it.

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

[Jim Porter]

Interestingly, I can't reproduce this on Emacs 30 (latest master), but I 
*can* on Emacs 28.2 and the latest rev on the Emacs 29 branch. I haven't 
dug any further yet to see which commit could have changed this though.

On 7/10/2023 1:57 PM, Jim Porter wrote:
> On 7/10/2023 10:28 AM, Stefan Monnier via Bug reports for GNU Emacs, the 
> Swiss army knife of text editors wrote:
>> Jim, did you collect various backtraces?  Do you still have them?
>> Can you check more thoroughly to try and see what they all have in common
>> (in addition to `ask-user-about-supersession-threat` and "Tramp")?

Ok, the common factors I can see right now are:

* 'ask-user-about-supersession-threat'
* Only happens when I press Enter

Tramp seems to have nothing to do with this.

>> Can you get an interactive backtrace buffer?  If so, I'd be curious to
>> know the values that
>>
>>      e (list auto-fill-function (default-value 'auto-fill-function)) RET
>>
>> returns and more importantly, how it varies from frame to frame.

The result appears to be (do-auto-fill do-auto-fill) everywhere.

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

[Jim Porter]

On 7/10/2023 2:54 PM, Jim Porter wrote:
> Interestingly, I can't reproduce this on Emacs 30 (latest master), but I 
> *can* on Emacs 28.2 and the latest rev on the Emacs 29 branch. I haven't 
> dug any further yet to see which commit could have changed this though.

... and it looks like you're the one who fixed this, Stefan! Should this 
get backported into the emacs-29 branch? It's a one-line fix, but I'm 
not sure if a fix to "src/eval.c" is too invasive for the release branch...

5223762e02ac84eee984cd1f7a17865766cdad9a is the first fixed commit
commit 5223762e02ac84eee984cd1f7a17865766cdad9a
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Sun Apr 2 17:45:58 2023 -0400

     src/eval.c: Fix bug#62419

     Yup, almost 40 years after ELisp first combined them, buffer-local
     and let bindings still don't work quite right :-(

     The "automatically buffer-local if set" semantics should follow the
     principle that it becomes buffer-local iff the var's current binding
     refers to the top-level/global/non-let binding.

     * src/eval.c (let_shadows_buffer_binding_p): Disregard non-global
     let-bindings.

     * test/src/eval-tests.el (eval-test--bug62419): New test.

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

[Eli Zaretskii]

> Date: Mon, 10 Jul 2023 16:53:41 -0700
> From: Jim Porter <jporterbugs@gmail.com>
> Cc: dhowells@redhat.com, Michael Albinus <michael.albinus@gmx.de>,
>  64439@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com>
> 
> On 7/10/2023 2:54 PM, Jim Porter wrote:
> > Interestingly, I can't reproduce this on Emacs 30 (latest master), but I 
> > *can* on Emacs 28.2 and the latest rev on the Emacs 29 branch. I haven't 
> > dug any further yet to see which commit could have changed this though.
> 
> ... and it looks like you're the one who fixed this, Stefan! Should this 
> get backported into the emacs-29 branch?

Sorry, no.  We've lived with this subtle problem for 40 years, we can
live another one or two.

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

[Jim Porter]

On 7/11/2023 4:31 AM, Eli Zaretskii wrote:
>> Date: Mon, 10 Jul 2023 16:53:41 -0700
>> From: Jim Porter <jporterbugs@gmail.com>
>> Cc: dhowells@redhat.com, Michael Albinus <michael.albinus@gmx.de>,
>>   64439@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com>
>>
>> On 7/10/2023 2:54 PM, Jim Porter wrote:
>>> Interestingly, I can't reproduce this on Emacs 30 (latest master), but I
>>> *can* on Emacs 28.2 and the latest rev on the Emacs 29 branch. I haven't
>>> dug any further yet to see which commit could have changed this though.
>>
>> ... and it looks like you're the one who fixed this, Stefan! Should this
>> get backported into the emacs-29 branch?
> 
> Sorry, no.  We've lived with this subtle problem for 40 years, we can
> live another one or two.

Ok, just thought I'd ask. It's not too hard to work around anyway.

For anyone who's interested, here's what I did to work around the bug in 
Emacs 29 and earlier:

--------------------

(use-package text-mode
   :preface
   (defun user/turn-on-auto-fill (&optional recursive)
     "Turn on `auto-fill-mode', but fix things if it got set globally.
See <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64439>."
     (turn-on-auto-fill)
     (when (default-value 'auto-fill-function)
       (message "`auto-fill-function' got set globally; fixing it...")
       (setq-default auto-fill-function nil)
       (when recursive
         (error (concat "Recursively setting the default value of "
                        "`auto-fill-function'!")))
       (run-with-timer 0 nil
                       (lambda (buf)
                         (with-current-buffer buf
                           (user/turn-on-auto-fill)))
                       (current-buffer))))

   :init
   (add-hook 'text-mode-hook (if (< emacs-major-version 30)
                                 #'user/turn-on-auto-fill
                               #'turn-on-auto-fill)))

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> For anyone who's interested, here's what I did to work around the bug in
> Emacs 29 and earlier:
>
> --------------------
>
> (use-package text-mode
>   :preface
>   (defun user/turn-on-auto-fill (&optional recursive)
>     "Turn on `auto-fill-mode', but fix things if it got set globally.
> See <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64439>."
>     (turn-on-auto-fill)
>     (when (default-value 'auto-fill-function)
>       (message "`auto-fill-function' got set globally; fixing it...")
>       (setq-default auto-fill-function nil)
>       (when recursive
>         (error (concat "Recursively setting the default value of "
>                        "`auto-fill-function'!")))
>       (run-with-timer 0 nil
>                       (lambda (buf)
>                         (with-current-buffer buf
>                           (user/turn-on-auto-fill)))
>                       (current-buffer))))

I suspect (i.e. don't take my word for it) a simpler workaround is to
(make-local-variable 'auto-fill-function) just before calling
`turn-on-auto-fill`.


        Stefan

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

[Jim Porter]

On 7/11/2023 11:44 AM, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> I suspect (i.e. don't take my word for it) a simpler workaround is to
> (make-local-variable 'auto-fill-function) just before calling
> `turn-on-auto-fill`.

No luck, unfortunately. But that's ok, my code is just temporary and 
I'll get to delete it sooner or later.

As for this bug, I think we can close it as a dupe of bug#62419? Any 
objections?

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

[Eli Zaretskii]

> Date: Tue, 11 Jul 2023 19:23:48 -0700
> Cc: dhowells@redhat.com, Eli Zaretskii <eliz@gnu.org>,
>  michael.albinus@gmx.de, npostavs@gmail.com, 64439@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> As for this bug, I think we can close it as a dupe of bug#62419? Any 
> objections?

No objections from me, no.

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

[Jim Porter]

On 7/3/2023 8:55 AM, David Howells wrote:
> I'm seeing an issue in which auto-fill-mode gets turned on for all the buffers
> in a running emacs instance, including the command entry window (M-x, grep,
> compile, etc.).

I've seen this too actually, but have had a hard time narrowing it down. 
I did something similar to Eli's suggestion a bit ago and did get a 
couple of data points, however:

* First, I have 'turn-on-auto-fill-mode' set on 'text-mode-hook'.

* It only seems to happen for me when a text-mode file was changed 
outside of Emacs, and then I press "r" (refresh) at the Emacs 
supersession prompt. This results in the mode being restarted (I think), 
which in turn calls 'turn-on-auto-fill-mode'. Occasionally, something 
gets messed up, and that function ends up setting the *default* value 
for 'auto-fill-function'.

* I usually notice this on files I'm editing over Tramp, but that might 
not be relevant since I use Tramp very heavily, and maybe I'm just 
getting "lucky".

I'm not sure, but perhaps there's a bug in 'set_internal'? There's some 
code in the 'SYMBOL_LOCALIZED' block of the switch statement in there 
that seems like it could relate to this, but I haven't had time to dig 
much into this, so that could be a red herring...

> In both cases, the emacs instances are typically running for multiple weeks
> till I need to reboot - or the issue becomes sufficiently irritating that I
> restart emacs.

Something like "(setq-default auto-fill-function nil)" should fix your 
Emacs session.