GNU bug report logs -
#78365
31.0.50; make-mode has no way to turn off confirmations before saving when it thinks there may be a syntax error
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Sun, May 11, 2025, 1:06 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Lynn Winebarger <owinebar <at> 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
[Message part 2 (text/html, inline)]
This bug report was last modified 94 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.