On Sun, May 11, 2025, 1:06 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > 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 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 , 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