From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Morgan Willcock Newsgroups: gmane.emacs.devel Subject: Re: Accidental change of behaviour for electric-layout-mode? Date: Wed, 25 Sep 2024 14:50:19 +0100 Message-ID: <87h6a37sh0.fsf@ice9.digital> References: <87wmj2dr4q.fsf@ice9.digital> <86v7yle1ma.fsf@gnu.org> <86cyktdx68.fsf@gnu.org> <871q18op24.fsf@ice9.digital> <86msjwdgcq.fsf@gnu.org> <87r098n8n5.fsf@ice9.digital> <86jzf0c6rw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15001"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 25 15:51:38 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1stSQZ-0003Zw-8C for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Sep 2024 15:51:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1stSPY-0000Hy-Kv; Wed, 25 Sep 2024 09:50:32 -0400 Original-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 1stSPX-0000Hp-Cv for emacs-devel@gnu.org; Wed, 25 Sep 2024 09:50:31 -0400 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stSPU-0006HO-A9; Wed, 25 Sep 2024 09:50:31 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 3D497C0007; Wed, 25 Sep 2024 13:50:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ice9.digital; s=gm1; t=1727272221; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SiyGhAztr2NQkAGukVh6EuT90UfsgLKV8BXDS64An7Y=; b=A/SHTWA4fV4kn//UCF9LskW4fLpw0ZefGbnboeFQG8GUfkHMvMD2LAr2RKsoscWKRl8d7M jmVNHx7uWpui1Qam90amb98P6sc8o7O2vKwQ+vbTf7/PuQVgq996yUjqf/8xC/43+L4NQs MFLEHqjZmQD9jvmGDWGsRGqJUSPvhy2CoYE0I3NGtcPHA2CukN/8dsZ8LQgH05hD3CnKph TCSPHF2WsmF+OF3+1ngElD068bzaNh/pPc4eR+l2/MBzbzxvkvVTODPrMP4/SAncc7+jVG COldvAqLnegD8qL4LICRShyHnP2W4mhS4j4b9gJsxXs2IPx1k3mXFv3AC/+NxA== In-Reply-To: <86jzf0c6rw.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Sep 2024 14:27:47 +0300") X-GND-Sasl: morgan@ice9.digital Received-SPF: pass client-ip=217.70.183.198; envelope-from=morgan@ice9.digital; helo=relay6-d.mail.gandi.net 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324069 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Morgan Willcock >> Cc: emacs-devel@gnu.org >> Date: Tue, 24 Sep 2024 20:39:42 +0100 >> >> Eli Zaretskii writes: >> >> >> Patch is attached. >> > >> > Thanks, but shouldn't the new variable be a defcustom, i.e. a user >> > option? AFAIU, the preference is on the user level. >> >> I am following the lead of electric-layout-allow-duplicate-newlines >> which is not a user option. > > Which ironically has the following comment: > > ;; TODO: Make this a defcustom? > (defvar electric-layout-allow-duplicate-newlines nil > > So I think this new variable should be a defcustom, and maybe we > should also make electric-layout-allow-duplicate-newlines a defcustom. > >> For my use case, electric-layout-rules is being set by a major-mode and >> the functions in those rules would need to be paired with the ability to >> insert a newline within a comment. > > If you are saying that it never makes sense to modify the value of > this variable given specific rules, i.e. that any set of rules will > either always support embedded newlines or be unable to support them, > but will never be able to sensibly support both alternatives, then I > agree. (But in that case, why do we need a variable at all? why not > let the rules specify this directly?) With the current setup, functions which are used within rules cannot decide for themselves on the context - the function call happens before the guards that have traditionally been in place are checked. >> If you needed another example of a major-mode configuring it, >> python-mode is also setting rules at the mode level: >> >> https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/progmodes/python.el?id=dfecd6037d5ebe5778c40ff7b38bfcbaa3ef779e > > The way to let modes control this behavior to introduce an internal > variable which the mode could set and whose initial default value is > taken from the user option. > >> >> If there is any doubt about the usage of the new variable I am happy to >> just put the original behaviour back and omit the new option for the >> moment. > > Do you really have such strong feelings about this not being a user > option that you'd rather forget the whole issue? Why are you so > convinced that no user will ever want to customize this behavior, when > you are the first example of such users? It is more that I don't have strong enough feelings to be making modifications which significantly change the user experience or design. Just to make sure everything works in Emacs 30, I'd rather just revert the accidental change than get further involved in the development of this feature (at least in the short term). I've attached a patch which just reverts the change that was accidentally applied. This should be all that is needed unless you specifically want to accommodate features which accidentally worked in an unreleased version of Emacs. -- Morgan Willcock --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Restore-comment-string-check-for-electric-layout-mod.patch >From 89463c6c5aeeae14868a69922719b5c154fbf69d Mon Sep 17 00:00:00 2001 From: Morgan Willcock Date: Wed, 25 Sep 2024 14:30:13 +0100 Subject: [PATCH] Restore comment/string check for electric-layout-mode This reverts an accidental change which allowed electric-layout-mode to insert newlines inside strings and comments. * lisp/electric.el (electric-layout-post-self-insert-function-1): Restore the previous default behavior of not inserting newlines within comments or strings. --- lisp/electric.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/electric.el b/lisp/electric.el index d02bcb4735b..2fcb90efe7d 100644 --- a/lisp/electric.el +++ b/lisp/electric.el @@ -409,7 +409,9 @@ electric-layout-post-self-insert-function-1 (goto-char pos) (funcall probe last-command-event)))) (when res (throw 'done res)))))))))) - (when rule + (when (and rule + ;; Not in a string or comment. + (not (nth 8 (save-excursion (syntax-ppss pos))))) (goto-char pos) (when (functionp rule) (setq rule (funcall rule))) (dolist (sym (if (symbolp rule) (list rule) rule)) -- 2.39.5 --=-=-=--