From unknown Sat Aug 16 00:34:41 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#78365 <78365@debbugs.gnu.org> To: bug#78365 <78365@debbugs.gnu.org> Subject: Status: 31.0.50; make-mode has no way to turn off confirmations before saving when it thinks there may be a syntax error Reply-To: bug#78365 <78365@debbugs.gnu.org> Date: Sat, 16 Aug 2025 07:34:41 +0000 retitle 78365 31.0.50; make-mode has no way to turn off confirmations befor= e saving when it thinks there may be a syntax error reassign 78365 emacs submitter 78365 Lynn Winebarger severity 78365 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat May 10 20:01:33 2025 Received: (at submit) by debbugs.gnu.org; 11 May 2025 00:01:34 +0000 Received: from localhost ([127.0.0.1]:53593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uDu8K-0006q7-W0 for submit@debbugs.gnu.org; Sat, 10 May 2025 20:01:33 -0400 Received: from lists.gnu.org ([2001:470:142::17]:41018) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uDu8D-0006pT-S6 for submit@debbugs.gnu.org; Sat, 10 May 2025 20:01:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uDu88-0000Fv-1S for bug-gnu-emacs@gnu.org; Sat, 10 May 2025 20:01:20 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uDu84-0000jP-Sd for bug-gnu-emacs@gnu.org; Sat, 10 May 2025 20:01:19 -0400 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3a0b77ea855so473544f8f.3 for ; Sat, 10 May 2025 17:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746921674; x=1747526474; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=OMhlGvG1I5E4qdDRA0zNujc9PbLKVwitAwHF6IGyXD4=; b=hMUlk8VDMV5pN5IJPsID77lbvgYEFAEGsTIz6IKFxkjlh6hpma7ZfQTll2uGAFWQQ4 u0nxGOs963saKLeEEEKP2end3zqtkM0vJDEEVBLpB8PfSdvsEoMQlO7S5gRYO5A3ddWJ zzGw++iOB/aylBapLTat3GQWGwUcQgU4A+ggUlAXC23wOh2AZss7uc4qahI+IkCkngJ6 Jks8F8jgK66Oy0Qa7FSZQE01DIaRkUU6s9fXIY7ar+1ZjqyPc+tHT88OGUi9twWyyJbJ OyEVmrXIkO2pL6OlIMI0H545oeCzGwfeHYuFxcNC79O9aJCvVslTNVL0ziqODkjHazNf LUlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746921674; x=1747526474; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OMhlGvG1I5E4qdDRA0zNujc9PbLKVwitAwHF6IGyXD4=; b=jLpvuj+F7KnvY2Sk1DD8yTZsmsKOcUnx3wqxTYpaqR6zA58lbXRv1G2frfY1LGwry8 G3ESHwN8GmVX96XNwQb6Y91NxtICdlu2Be5lQEwcxVQTqkCasdYpXcZMsSqyTeQkscQ6 Q6gAnyMQS0bnJMks8W6ktrq41hSh4V4Gfd0IZL+Xoir3sSziOdtmR5yuJtNjhYGPfE+a G2GcaDuVI3YTou9ablETg68840Gqj8T4udob90SUws4EMuqwz+4BP+P0ZNyx5Pwb7OMA 9b4VRUS8dTt1tW7jv++iLbEXEHbp4oep/F2j6UoKrVp7uFmtn3rIwnqp6rRYiYUG2mgP Upbw== X-Gm-Message-State: AOJu0Yymj8GX51u8QtnlWTzGAywMDs2qeywusrNBRmVuBN4731NRabxc Eh+BLAv9reZ1zW5rkE/nJPaCp4bn35/aPb8yLDU7ORd9cM4k7vp2E3kok/U+U/DCOKrnDlL8l7P P0au6Vx8zChdCYghH+XfBm7BkLod7E66k X-Gm-Gg: ASbGnctgxf341LczBYQvCBWFybdyQxasFZN9hiwSjG00OmYFctwmhgzqPyeEFNbAcd7 A5eLXVGQT25R78UL/A7f32RnPSypAdbV1PsQlIdAIW9uh1uKbAcL6Q6GsQGo4sjamBdAaq03eM6 iEP50XXo6VfPG+CKuuTrsjVjKIYRhrTGqB1NMpcnfnOnIvWow2VosO3Bwf X-Google-Smtp-Source: AGHT+IGmy0xFZ1g1+N1JbswrapYbuPkqA+UBDM7cdf0I9VDMsykBMaVVkOnoBnlkl6jaTZ/KaxrZ1HHJgADvrUrf5Yk= X-Received: by 2002:a05:6000:2dc4:b0:38f:2b3c:569e with SMTP id ffacd0b85a97d-3a1f647ff9dmr2156255f8f.11.1746921673601; Sat, 10 May 2025 17:01:13 -0700 (PDT) MIME-Version: 1.0 From: Lynn Winebarger Date: Sat, 10 May 2025 20:01:01 -0400 X-Gm-Features: AX0GCFuZiG9vOMtB13FLCn6IkYcUS05PV6F5rcNJFGnWMJVk3bFCkX_a0YmRH6M Message-ID: Subject: 31.0.50; make-mode has no way to turn off confirmations before saving when it thinks there may be a syntax error To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="000000000000cf6eaf0634d0e57b" Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=owinebar@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000cf6eaf0634d0e57b Content-Type: text/plain; charset="UTF-8" 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. 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. I have attached a patch to let the user set the list of hooks that will be run when the buffer is written, with the default being the current set that are used. At least I can set it to nil. In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) Repository revision: 2bced74aa9735d9a9a5cb00aedfcac72d54f5d50 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101011 System Description: openSUSE Leap 15.6 Configured using: 'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type 'CFLAGS=-O0 -g3' --infodir=/usr/local/share/emacs/31/share/info --mandir=/usr/local/share/emacs/31/share/man --docdir=/usr/local/share/emacs/31/share/doc/emacs --localedir=/usr/local/share/emacs/31/share/locale --with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-rsvg --with-imagemagick --with-dbus --with-gpm --with-x-toolkit=gtk3 --with-toolkit-scroll-bars --with-libotf --with-m17n-flt --with-cairo --disable-build-details --without-pop --with-mailutils --without-hesiod --with-gameuser=:games --with-kerberos --with-kerberos5 --with-file-notification=inotify --with-modules --with-tree-sitter -C' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ IMAGEMAGICK JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB Important settings: value of $LANG: en_US.utf8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: global-semanticdb-minor-mode: t global-semantic-idle-breadcrumbs-mode: t global-semantic-idle-completions-mode: t global-semantic-idle-scheduler-mode: t global-semantic-idle-local-symbol-highlight-mode: t global-semantic-idle-summary-mode: t global-semantic-highlight-func-mode: t global-semantic-stickyfunc-mode: t global-semantic-show-parser-state-mode: t global-semantic-highlight-edits-mode: t semantic-mode: t global-so-long-mode: t global-hl-line-mode: t hexl-follow-ascii: t windmove-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t global-prettify-symbols-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t buffer-read-only: t column-number-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils help-at-pt time-date semantic/db-mode semantic/idle semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn semantic/db semantic/format semantic/tag-ls semantic/find semantic/ctxt semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw ede/speedbar ede/files ede cl-extra ede/detect ede/base ede/auto ede/source eieio-base eieio-speedbar eieio-custom cedet delsel cus-load allout-widgets allout smerge-mode ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util treesit-x transient format-spec edmacro kmacro time html-ts-mode conf-mode emacs-authors-mode emacs-news-mode refer nroff-mode table remember sgml-mode facemenu dom yaml-ts-mode underline texinfo texinfo-loaddefs term disp-table ehelp tab-line tempo so-long sqlite-mode skeleton scroll-lock rtree reveal pulse color profiler proced pcmpl-x pcmpl-linux pcmpl-git vc-git files-x vc-dispatcher noutline outline misc hi-lock ibuffer ibuffer-loaddefs hl-line hexl ffap chart bindat avl-tree disass memory-report mode-local lisp-mnt edebug ielm hippie-exp image-file image-converter autoconf autoconf-mode c++-ts-mode c-ts-mode c-ts-common etags fileloop generator make-mode gud inf-lisp shell pcomplete hideshow ruler-mode speedbar ezimage dframe sqlite treesit windmove eglot tree-widget wid-edit external-completion jsonrpc xref flymake thingatpt project diff diff-mode track-changes easy-mmode ert pp ewoc debug backtrace help-mode find-func filenotify warnings compile text-property-search comint ansi-osc ansi-color ring pcase imenu ispell package browse-url xdg url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib info rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar make-network-process tty-child-frames emacs) Memory information: ((conses 16 224623 38463) (symbols 48 25118 0) (strings 32 69778 2204) (string-bytes 1 1825120) (vectors 16 44197) (vector-slots 8 443913 13792) (floats 8 215 2) (intervals 56 553 0) (buffers 992 14)) --000000000000cf6eaf0634d0e57b Content-Type: text/x-patch; charset="US-ASCII"; name="make-mode.patch" Content-Disposition: attachment; filename="make-mode.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_maiw1rjj0 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL21ha2UtbW9kZS5lbCBiL2xpc3AvcHJvZ21vZGVz L21ha2UtbW9kZS5lbAppbmRleCBkNWZkZDA2MzgyNS4uZWMxYWM0ZTlkNGYgMTAwNjQ0Ci0tLSBh L2xpc3AvcHJvZ21vZGVzL21ha2UtbW9kZS5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9tYWtlLW1v ZGUuZWwKQEAgLTE4OCw2ICsxODgsMTUgQEAgbWFrZWZpbGUtY2xlYW51cC1jb250aW51YXRpb25z CiB0byBNT0RJRlkgQSBGSUxFIFdJVEhPVVQgWU9VUiBDT05GSVJNQVRJT04gd2hlbiBcIml0IHNl ZW1zIG5lY2Vzc2FyeVwiLiIKICAgOnR5cGUgJ2Jvb2xlYW4pCiAKKyhkZWZjdXN0b20gbWFrZWZp bGUtd3JpdGUtY2hlY2staG9va3MKKyAgJyhtYWtlZmlsZS13YXJuLXN1c3BpY2lvdXMtbGluZXMK KyAgICBtYWtlZmlsZS13YXJuLWNvbnRpbnVhdGlvbnMKKyAgICBtYWtlZmlsZS1jbGVhbnVwLWNv bnRpbnVhdGlvbnMpCisgICJMaXN0IG9mIGZ1bmN0aW9ucyB0byBydW4gd2hlbiB3cml0aW5nIHRo ZSBidWZmZXIgdG8gYSBmaWxlLgorVGhlIGRlZmF1bHRzIG9uIHRoZSBsaXN0IHJlcXVpcmUgY29u ZmlybWF0aW9uIHRvIHNhdmUgd2hlbiBhCitzdXNwaWNpb3VzIGxpbmUgb3IgbGluZSBjb250aW51 YXRpb24gaXMgZGV0ZWN0ZWQuIgorICA6dHlwZSAnbGlzdCkKKwogKGRlZmN1c3RvbSBtYWtlZmls ZS1tb2RlLWhvb2sgbmlsCiAgICJOb3JtYWwgaG9vayBydW4gYnkgYG1ha2VmaWxlLW1vZGUnLiIK ICAgOnR5cGUgJ2hvb2spCkBAIC04MjMsMTIgKzgzMiw4IEBAIG1ha2VmaWxlLW1vZGUKICAgIGF0 IHRoZSBiZWdpbm5pbmcgb2YgYSBsaW5lIGluIE1ha2VmaWxlIG1vZGUuIgogICAoYWRkLWhvb2sg J2NvbXBsZXRpb24tYXQtcG9pbnQtZnVuY3Rpb25zCiAgICAgICAgICAgICAjJ21ha2VmaWxlLWNv bXBsZXRpb25zLWF0LXBvaW50IG5pbCB0KQotICAoYWRkLWhvb2sgJ3dyaXRlLWZpbGUtZnVuY3Rp b25zCi0JICAgICdtYWtlZmlsZS13YXJuLXN1c3BpY2lvdXMtbGluZXMgbmlsIHQpCi0gIChhZGQt aG9vayAnd3JpdGUtZmlsZS1mdW5jdGlvbnMKLQkgICAgJ21ha2VmaWxlLXdhcm4tY29udGludWF0 aW9ucyBuaWwgdCkKLSAgKGFkZC1ob29rICd3cml0ZS1maWxlLWZ1bmN0aW9ucwotCSAgICAnbWFr ZWZpbGUtY2xlYW51cC1jb250aW51YXRpb25zIG5pbCB0KQorICAoZG9saXN0IChoIG1ha2VmaWxl LXdyaXRlLWNoZWNrLWhvb2tzKQorICAgIChhZGQtaG9vayAnd3JpdGUtZmlsZS1mdW5jdGlvbnMg aCBuaWwgdCkpCiAgIChtYWtlLWxvY2FsLXZhcmlhYmxlICdtYWtlZmlsZS10YXJnZXQtdGFibGUp CiAgIChtYWtlLWxvY2FsLXZhcmlhYmxlICdtYWtlZmlsZS1tYWNyby10YWJsZSkKICAgKG1ha2Ut bG9jYWwtdmFyaWFibGUgJ21ha2VmaWxlLWhhcy1wcmVyZXFzKQo= --000000000000cf6eaf0634d0e57b-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 01:06:59 2025 Received: (at 78365) by debbugs.gnu.org; 11 May 2025 05:06:59 +0000 Received: from localhost ([127.0.0.1]:55906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uDytu-0001BU-Oo for submit@debbugs.gnu.org; Sun, 11 May 2025 01:06:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54300) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uDyts-0001B8-Vn for 78365@debbugs.gnu.org; Sun, 11 May 2025 01:06:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uDytn-0004lU-NM; Sun, 11 May 2025 01:06:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=oB834flxkcGpwWGargopdMKtXQGTMs1uuNHCcZ7wO/Q=; b=QwqYMWAttuCK fYDtk1AIxBzIq6zkyjJJVF/PFLu1i8Z4NnhDUHKHpLy6868KOYyXW+krloD8RQZVuLnOBWY0rnOMa 3RLD2GE1M2RhqX8BBt4SsN67WQ8s2D2HpoBJeWmTOwDTl6k8mV4Xxwb+drzRlIdZUKnk3mylX0B9n esXWUqALUiSyQyCeTtlFzg22ZQSTZgtjWUbvjFKkfvx5thnHFvUhUi/URGp7T6AOcvwtAYlQn15pJ dZ1CjMFNo1s3ipNUoAb+TKlsL39lEoGDeXCP9Cvy8UyDCOjveFZMfZLAuzk4FOcuJU3amT5EIXirE a5ez8y5JEW4xXEp8aeot7g==; Date: Sun, 11 May 2025 08:06:48 +0300 Message-Id: <86jz6n91nb.fsf@gnu.org> From: Eli Zaretskii To: Lynn Winebarger In-Reply-To: (message from Lynn Winebarger on Sat, 10 May 2025 20:01:01 -0400) 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 References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78365 Cc: 78365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? > 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. > 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.) From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 07:34:57 2025 Received: (at 78365) by debbugs.gnu.org; 11 May 2025 11:34:57 +0000 Received: from localhost ([127.0.0.1]:59400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uE4xK-0002X5-52 for submit@debbugs.gnu.org; Sun, 11 May 2025 07:34:56 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:39263) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uE4xG-0002WF-9f for 78365@debbugs.gnu.org; Sun, 11 May 2025 07:34:51 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-43e9ccaa1ebso1494355e9.1 for <78365@debbugs.gnu.org>; Sun, 11 May 2025 04:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746963284; x=1747568084; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MzXAA4Bkev3g9kJ8Gdeaj0I8Cx3DmR4BBYfR03Wftws=; b=ciOa8Pvsu7Pb7+S0A8M3ereNfkPvNtuH6Hf+y8Z0RfkcIeOX11YcMzXvL79JQFMURM wisaWxY45k1NJCn/A3tSxW/QaWMAceB84NaD/euGoC+Mfz5Y3z9lNYjS7RdZAkD85NR0 ngiTtIBMgbsiHaI7cW/lZDI3KUVd2Ca9qID9QSqi9gmCKtzW9ZCpx8l7/SJHy+Xx1tNJ QYlcis/DIJLA6oz1Dy428Ojh7xCwLA1/5nU1yl7TPXCdJN9eTIPoQ9X/BCFgSqPvALUp KJICdvNl3EWQQueP4j63zvsQk3ZcftZXbwp+1z7pg/prvu8fQM62by4JMk5GrOXab5Mo 3hhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746963284; x=1747568084; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MzXAA4Bkev3g9kJ8Gdeaj0I8Cx3DmR4BBYfR03Wftws=; b=gsnMzBIrPXmOSxBg4ZbZSbqz6NWVfHn1lF17vL6xt5KOgreYWC3YXDjz3g2dkQ/tQz kZOpGVUvodP/F+6rgtfKDBJNhFPw2LOI/hjFXxzHaohCMmjsGKMPfLOrKgmwEac3YAAU GhO9GRxR6GGP+N+bAx+25atXQ9dJ3ZSd1vPhrL6ktgmrCsHBLmqqdCOjiwMhjsb04N0L AJweuWSN3We9lCa5fiJEjbOWgDuj+iO23nHmvRA5LWhKot8zKsHwZX3IU9Sz4JzoQCOq OEFibDFvhWKlNF5HK8W1FmkXOT0/juuUr3z0/5DXKj0sp5Vr++TINj7ioMrmWIeHc2zw LH+A== X-Gm-Message-State: AOJu0Yz4d+jhcGJWJfPnSin81hk6cBhTKvIkRcA12F9CUcbQsJt+5CLK iHZeb1F67da0gcR1CaXQiJSyBK0RmApKmj9YA8HYa1YxgXnLz2rbLpIHUJ7wuRfnM7QMRL32ZWe ri+NB6m8+b1oSIe8EUl152O+QDfaVag== X-Gm-Gg: ASbGncsUvvIuwnyp+CmV8Jik/bm0VrDx2u0e3h3QrXBE/ouK/S7laJC3563BcbYD3QK XQ7Ln55e3HnKK3STr45LSAIzRo9YITTEH01cKjPeBgoaXFbPn3+9I0s8z6yOYuoVsOGJa6tQGQr TklONHguvrVdiSeFlNoRfXEM3PENuwoC8c4mjnQX179M4OfSKxm5xrQc3pAS6m/8vg X-Google-Smtp-Source: AGHT+IGX4NSug3e02yq6OraOAAVt2E5BM8GxXBPhP1l7+U8L17bBQPSDb8ysR0Y8QXFohzM/qPrg9cSQ6lu9z9wXgbQ= X-Received: by 2002:a05:600c:37c6:b0:442:ccfa:215 with SMTP id 5b1f17b1804b1-442d6ddd215mr26662965e9.6.1746963283734; Sun, 11 May 2025 04:34:43 -0700 (PDT) MIME-Version: 1.0 References: <86jz6n91nb.fsf@gnu.org> In-Reply-To: <86jz6n91nb.fsf@gnu.org> From: Lynn Winebarger Date: Sun, 11 May 2025 07:34:33 -0400 X-Gm-Features: AX0GCFvO7PFrtjoomoTx4wD9jl-3MG8HjltU6hUhXXO_k4hj2N7BjtmEh7U2Nqo Message-ID: 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 To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000f677170634da95cd" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78365 Cc: 78365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000f677170634da95cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 11, 2025, 1:06=E2=80=AFAM 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 whethe= r > > 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 --000000000000f677170634da95cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 11, 202= 5, 1:06=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Lynn Winebarger <<= a href=3D"mailto:owinebar@gmail.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">owinebar@gmail.com>
> Date: Sat, 10 May 2025 20:01:01 -0400
>
> I've been hacking on Makefiles, and I habitually save while rewrit= ing,
> not just when I have a finished edit.=C2=A0 I may also have autosave t= urned
> on.=C2=A0 There were annoying confirmation requests when that happened= , and
> if I did not notice (maybe due to autosave), the requests pile up and<= br> > once a later one has been answered, an earlier one reappears but eithe= r
> can't accept the input or maybe there were a bunch of warnings que= ued
> up.

AFAIU, autosave is not supposed to run these hooks, so if that
happened to you, it's a bug.=C2=A0 Can you show a recipe for reproducin= g
this?

<= div dir=3D"auto">I've been editing in one frame with info manuals open = in other frames on other monitors.=C2=A0 So I would type <C-x s> in t= he Makefile buffer with a "suspicious line" far away from the poi= nt 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 ori= ginal buffer, ... several times before noticing the request for confirmatio= n.=C2=A0 Then I would type y, the file will be written, but another confirm= ation prompt is immediately displayed, but it may or may not be able to acc= ept my response, even after I switch focus back to the minibuffer.=C2=A0 I = don't know if that was correlated to my typing multiple "y"&#= 39;s in the buffer before I realized answering the first confirmation put m= e back in the buffer, even though the subsequent prompt displayed immediate= ly 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.=C2= =A0 I
> don't know.=C2=A0 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.=C2=A0 Especially since your proposed
solution is quite a blunt weapon.=C2=A0 These functions are placed on
write-file-functions for a reason.

I did not anticipate this behavior has been in place 20+ years (jus= t looked at the blame).=C2=A0 I understand a Makefile may be regarded as a = previous component of a build system rather than a programming language, bu= t this intrusive approach is unlike any other programming language mode I r= ecall using in emacs.=C2=A0 I understand why it might be the default, but f= or that to not even be configurable was jarring.
So, I thought this had to be a recent addition I w= as just pushing back on, as I am manually setting this hook to nil as a sto= p-gap now, for every buffer I am using to actively develop a Makefile.=C2= =A0 I didn't object to it being the default behavior.

Another approach would be to have a custo= mization variable to treat Makefiles as precious or not by default.=C2=A0 T= hen have a Boolean buffer local variable initialized to that setting that i= s consulted by those functions, and a command to flip that treatment in a p= articular buffer, so they can be freely hacked upon before they are actuall= y in use.=C2=A0 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
>=C2=A0 to MODIFY A FILE WITHOUT YOUR CONFIRMATION when \"it seems = necessary\"."
>=C2=A0 =C2=A0 :type 'boolean)
>=C2=A0
> +(defcustom makefile-write-check-hooks
> +=C2=A0 '(makefile-warn-suspicious-lines
> +=C2=A0 =C2=A0 makefile-warn-continuations
> +=C2=A0 =C2=A0 makefile-cleanup-continuations)
> +=C2=A0 "List of functions to run when writing the buffer to a fi= le.
> +The defaults on the list require confirmation to save when a
> +suspicious line or line continuation is detected."
> +=C2=A0 :type 'list)

The :version tag is missing.=C2=A0 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 behavi= or has been standard for 20+ years, I'd agree.
<= br>
Lynn

--000000000000f677170634da95cd--