From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#60162: [PATCH] * lisp/cus-edit.el (setopt--set): Warn instead of rasing an error Date: Sat, 17 Dec 2022 22:19:03 +0000 Message-ID: <87wn6py8q0.fsf@posteo.net> References: <87a63mvvib.fsf@posteo.net> <87y1r56hbo.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34897"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "60162@debbugs.gnu.org" <60162@debbugs.gnu.org> To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 17 23:20:22 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p6fXZ-0008v6-Ig for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Dec 2022 23:20:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6fXK-0003xF-F8; Sat, 17 Dec 2022 17:20:06 -0500 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 1p6fXG-0003ws-F3 for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2022 17:20:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p6fXG-0000EV-5r for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2022 17:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p6fXF-0002S1-VI for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2022 17:20:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Dec 2022 22:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60162 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 60162-submit@debbugs.gnu.org id=B60162.16713155609402 (code B ref 60162); Sat, 17 Dec 2022 22:20:01 +0000 Original-Received: (at 60162) by debbugs.gnu.org; 17 Dec 2022 22:19:20 +0000 Original-Received: from localhost ([127.0.0.1]:58267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6fWZ-0002Ra-Rq for submit@debbugs.gnu.org; Sat, 17 Dec 2022 17:19:20 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:49471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6fWY-0002RT-3u for 60162@debbugs.gnu.org; Sat, 17 Dec 2022 17:19:19 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1F5D7240107 for <60162@debbugs.gnu.org>; Sat, 17 Dec 2022 23:19:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1671315552; bh=Jd0nwDIgrySOFkKxVyfsfsinUuXvCKswN1UAThjBvAo=; h=From:To:Cc:Subject:Date:From; b=dJgFOPCA81j0YLeaY5NNrbJWizzM0rUs9Iiha4OSyUwRcFjGz/uV3Mb6vi5W2vL7q WuFyTk30XKc8cdii+2463wrk4QYqO8YH2mhVQVFhyxF3O8Q7qNRm5Kj8FgdpQIx+Db Lydm3a14xCdj78AD8/3+NpkPa+A9DNo7uT26ot/Iucv41vs0XkK1tL1czMOcfciTDp N4M96ChVT8XpIHgmTROOv9MBD6SOdaI4eAXHmuRL7RG3Yw4aCgYySY2uuOFZ/2P3Jw 6nP9iRc/o6UQMXAm05ookTNw/fr0rgah6aAGnackawBZA0/0vK2h+4DLLVDsxsXuhK L+7OeNJbMVkaQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NZL3Z533Xz6tq0; Sat, 17 Dec 2022 23:19:03 +0100 (CET) In-Reply-To: (Drew Adams's message of "Sat, 17 Dec 2022 20:53:43 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:251315 Archived-At: Drew Adams writes: >> `customize-set-variable' isn't used at all, >> to prevent modifying the user theme. > > 1. Why? > > Why should the two differ wrt whether theme `user' > gets modified? Why does updating that theme make > sense in the one case but not in the other? If a user option is added to the user theme, then this "pollutes" the `custom-set-variables' block which is IMHO pointless, since the changes are usually already made programmaticaly, so double-saving them will usually cause more fuss than be of any use. > 2. And now that this is brought to my attention, I > really wonder why `customize-set-variable' pushes > the new setting to the `user' theme. So that it is clear what option have to be saved, when customised using the Easy Customization Interface. > AFAIK, there's nothing at all that requires, or that > should assume, that that function is called by the > current user, or that even if it is, that that user > wants theme `user' updated that way. > > This is apparently the case at least since Emacs 22. > Emacs 20 had no custom themes, and I don't have the > source for Emacs 21. But a guess is that whoever > (Chong Yidong?) added custom themes to Emacs decided > to add this to `customize-set-variable'. > > 3. Why is modifying theme `user' a good idea for any > function that changes an option value? Especially, > why should that be hardcoded (i.e., not an optional > parameter)? You mean why "user" and not some other theme? > I see that we modify themes when a _face_ is changed > with `face-spec-set' (via `face-spec-recalc'). But > I don't see that we do that if you instead use > `set-face-attribute' or similar. What criteria decide > whether to modify themes when a face gets modified? > > 5. Does the Emacs 29 manual call out this difference > between `setopt' and `customize-set-variable'? I see > it only in your email, not in the doc strings or the > code comments (in what you included in your mail). (What happened to 4?) It isn't mentioned in either the Emacs or the Elisp manual. > 6. Coming back to your fix: why is warning instead > of raising an error TRT? You say it's to be able to > continue loading an init file. Do we do that with > other attempts to set a user option/face to a bad > value when loading code? I think not. For > `customize-set-variable', `customize-set-value', and > `setq'/`set' we issue no warning and raise no error. > > Runtime "warnings" are generally a _bad_ idea, IMO. > Even "warnings" during code loading are a bad idea. > My suggestion is to either raise an error or do what > `customize-set-variable' and the rest do, which is > set the value and ignore whether it might be bad - > don't even test it. Well an error is already being raised, but as I said, it is my impressions this is too strict. Typing mistakes in regards to user options aren't great, but certainly shouldn't be fatal. Or I haven't ever regarded them as something reliable enough to just assume will always hold -- after all, you can bypass the type checking. The initial version of the macro didn't even have type-checking. It was added later as a convenience feature to assist the user and inform them if a mistake was made but also to incentivise package developers to add types to user options. > ___ > > `setopt' was added for Emacs 29, which isn't out yet. > Is the behavior appropriate? What's the rationale, > besides not having to quote and allowing for multiple > settings? Other than quoting, why should it behave > differently from `customize-set-variable'?