On Sun, May 11, 2025, 1:06 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Lynn Winebarger <owinebar@gmail.com>
> 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