From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: custom-set-variables considered harmful Date: Fri, 1 Dec 2017 17:58:23 -0800 (PST) Message-ID: <66c7b088-e9e9-4d31-b7e3-3c8f8b660814@default> References: <8782ed42-3aec-4111-b4f0-471c838e7370@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1512179930 12365 195.159.176.226 (2 Dec 2017 01:58:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Dec 2017 01:58:50 +0000 (UTC) Cc: philippe.vaucher@gmail.com, lokedhs@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org, rswgnu@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 02 02:58:46 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKx4k-0002a1-Iu for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 02:58:42 +0100 Original-Received: from localhost ([::1]:33855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKx4o-0004xC-Gg for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 20:58:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKx4c-0004wo-S9 for emacs-devel@gnu.org; Fri, 01 Dec 2017 20:58:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKx4Y-0004M4-06 for emacs-devel@gnu.org; Fri, 01 Dec 2017 20:58:34 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:21462) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eKx4X-0004LM-PO; Fri, 01 Dec 2017 20:58:29 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vB21wQwt021570 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 2 Dec 2017 01:58:27 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vB21wPs3001752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 2 Dec 2017 01:58:25 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vB21wOmB024059; Sat, 2 Dec 2017 01:58:25 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220604 Archived-At: >> =E2=80=8BI have been wondering about this too. Are there any arguments = for >> not having setq run the setter of a custom option when available? >=20 > That change would create a risk of bugs in many parts of the code. > Each differnt kind of setter function creates a different risk of > possible errors. >=20 > That change would mean that making an ordinary let binding could run > arbitrary Lisp code. Unwinding the binding could also run arbitrary > Lisp code. >=20 > Finally, it could cause errors in places that set the variable and > expect that to do nothing but put a new value in it. This includes > the definitions of setter functions, right? As I said, I don't argue for doing this. And yes, there would need to also be a "basic setq", which has the current behavior, to be able to use in custom functions (e.g. setters) and some other places. I figured that much was obvious. The other considerations you mention are less clear to me. I suppose another possibility might be to come up with another function, with a short name, that does what we're talking about: does `customize-set-variable' for an option (except in `custom*' code) and does `setq' otherwise. And then encourage people to use that new function instead of `setq' most places. I kinda doubt that would help much, though. But again, I'm not proposing any of this. I mentioned it only as food for thought. The problem to solve (which is admittedly a small one, since as Stefan pointed out most options don't use special :set functions) is that users seem to often use `setq' for options without even being aware of `customize-set-variable' or why it might be needed in some cases.