Subject: Re: bug#78365: 31.0.50; make-mode has no way to turn off confirmations before saving when it thinks there may be a syntax error

From: Lynn Winebarger <[email-masked]>
Date: Sun, 11 May 2025 07:34:33 -0400

On Sun, May 11, 2025, 1:06 AM Eli Zaretskii <[email-masked]> wrote:

> > From: Lynn Winebarger <[email-masked]>
> > Date: Sat, 10 May 2025 20:01:01 -0400
> >
> > I've been hacking on Makefiles, and I habitually save while rewriting,
> > not just when I have a finished edit.  I may also have autosave turned
> > on.  There were annoying confirmation requests when that happened, and
> > if I did not notice (maybe due to autosave), the requests pile up and
> > once a later one has been answered, an earlier one reappears but either
> > can't accept the input or maybe there were a bunch of warnings queued
> > up.
>
> AFAIU, autosave is not supposed to run these hooks, so if that
> happened to you, it's a bug.  Can you show a recipe for reproducing
> this?
>

I've been editing in one frame with info manuals open in other frames on
other monitors.  So I would type <C-x s> in the Makefile buffer with a
"suspicious line" far away from the point I was editing, then go to the
manual, then return focus to the original buffer, edit a little more, type
<C-x s>, consult manual, back to original buffer, ... several times before
noticing the request for confirmation.  Then I would type y, the file will
be written, but another confirmation prompt is immediately displayed, but
it may or may not be able to accept my response, even after I switch focus
back to the minibuffer.  I don't know if that was correlated to my typing
multiple "y"'s in the buffer before I realized answering the first
confirmation put me back in the buffer, even though the subsequent prompt
displayed immediately after I responded to the first (that seems like a
completely independent problem from the lack of configurability).

> > Or maybe there was some kind of implicit loop, where confirming the
> > save after some timer ran out caused another confirmation request.  I
> > don't know.  But there's no customization to let the user decide whether
> > they want this intrusive behavior.
>
> It would be good to understand the problem and its causes before we
> discuss the possible solutions.  Especially since your proposed
> solution is quite a blunt weapon.  These functions are placed on
> write-file-functions for a reason.
>

I did not anticipate this behavior has been in place 20+ years (just looked
at the blame).  I understand a Makefile may be regarded as a previous
component of a build system rather than a programming language, but this
intrusive approach is unlike any other programming language mode I recall
using in emacs.  I understand why it might be the default, but for that to
not even be configurable was jarring.

So, I thought this had to be a recent addition I was just pushing back on,
as I am manually setting this hook to nil as a stop-gap now, for every
buffer I am using to actively develop a Makefile.  I didn't object to it
being the default behavior.

Another approach would be to have a customization variable to treat
Makefiles as precious or not by default.  Then have a Boolean buffer local
variable initialized to that setting that is consulted by those functions,
and a command to flip that treatment in a particular buffer, so they can be
freely hacked upon before they are actually in use.  For extra credit,
commands that are use to build a project might detect the Makefile is open
and set the flag to t while the build is running to prevent a race.

> > diff --git a/lisp/progmodes/make-mode.el b/lisp/progmodes/make-mode.el
> > index d5fdd063825..ec1ac4e9d4f 100644
> > --- a/lisp/progmodes/make-mode.el
> > +++ b/lisp/progmodes/make-mode.el
> > @@ -188,6 +188,15 @@ makefile-cleanup-continuations
> >  to MODIFY A FILE WITHOUT YOUR CONFIRMATION when \"it seems necessary\"."
> >    :type 'boolean)
> >
> > +(defcustom makefile-write-check-hooks
> > +  '(makefile-warn-suspicious-lines
> > +    makefile-warn-continuations
> > +    makefile-cleanup-continuations)
> > +  "List of functions to run when writing the buffer to a file.
> > +The defaults on the list require confirmation to save when a
> > +suspicious line or line continuation is detected."
> > +  :type 'list)
>
> The :version tag is missing.  Also, this kind of change warrants a
> NEWS entry.
>
> (But I'm still not sure this change is TRT for solving the problems
> you described, for lack of details.)
>

Yes, once I saw this behavior has been standard for 20+ years, I'd agree.

Lynn