[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64439: 28.2; auto-fill-mode gets turned on all over the place
From: |
Eli Zaretskii |
Subject: |
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@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, David Howells, 2023/07/03
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Eli Zaretskii, 2023/07/03
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, David Howells, 2023/07/03
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Eli Zaretskii, 2023/07/03
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/09
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Eli Zaretskii, 2023/07/09
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/09
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place,
Eli Zaretskii <=
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/10
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Michael Albinus, 2023/07/10
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Stefan Monnier, 2023/07/10
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/10
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/10
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/10
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Eli Zaretskii, 2023/07/11
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/11
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Stefan Monnier, 2023/07/11
- bug#64439: 28.2; auto-fill-mode gets turned on all over the place, Jim Porter, 2023/07/11