From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Accidental change of behaviour for electric-layout-mode? Date: Wed, 25 Sep 2024 14:27:47 +0300 Message-ID: <86jzf0c6rw.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15259"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Morgan Willcock Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 25 13:28:47 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 1stQCN-0003hs-4P for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Sep 2024 13:28:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1stQBU-0000CX-OD; Wed, 25 Sep 2024 07:27:52 -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 1stQBT-00008T-It for emacs-devel@gnu.org; Wed, 25 Sep 2024 07:27:51 -0400 Original-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 1stQBR-0005vN-Vh; Wed, 25 Sep 2024 07:27:50 -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=Zh85I8VjzdTiH/CEDQAsvixCqNFBUs0i6VvMTb3/asM=; b=GOHLSQ1VfLKA 5hql4BrphQJc77sj7txaby+gbpRez4huiBS33S+vAo5+KcW6GIj+afLIPQ9JZoeRXuYFApvTkZOif LYukWG/0BZy1KTWlH7eOej11BkKvvNW3F+RpVgfHvqv9xt3sEy4PXf92sDHl8ew0ftNCtIaktIO3s O/RAIS8sjgI+v7G/blFGRWzv9/NHASs707E0ylUJ+fUlL+VrtnJcC7xGHTMpxVicDmtT8rxufgmxh J9zKX5+oToaGeXuysm5Ox8nQY54nAayrB8mTPTrfZ5aYIf0O69C0AcQvoIDPgKxsuC2tL9I49H9oT XsNET9Y5IOJYGUeLPPZlwg==; In-Reply-To: <87r098n8n5.fsf@ice9.digital> (message from Morgan Willcock on Tue, 24 Sep 2024 20:39:42 +0100) 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:324061 Archived-At: > 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?) > 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? > > Also, this needs a NEWS entry. > > Does it need a NEWS entry if it is not a user option and the default > behaviour is the same as Emacs 29? Let's first agree about the option issue, and then get back to NEWS. Thanks.