From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Vivek Dasmohapatra Newsgroups: gmane.emacs.devel Subject: Re: custom-set-variables considered harmful Date: Wed, 8 Nov 2017 14:23:00 +0000 (GMT) Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1386749776-1510150980=:27794" X-Trace: blaine.gmane.org 1510150993 2503 195.159.176.226 (8 Nov 2017 14:23:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Nov 2017 14:23:13 +0000 (UTC) User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 08 15:23:09 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 1eCRFz-0000QA-8W for ged-emacs-devel@m.gmane.org; Wed, 08 Nov 2017 15:23:07 +0100 Original-Received: from localhost ([::1]:59919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCRG6-00034H-JQ for ged-emacs-devel@m.gmane.org; Wed, 08 Nov 2017 09:23:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCRG0-000341-BJ for emacs-devel@gnu.org; Wed, 08 Nov 2017 09:23:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCRFx-0005w3-7U for emacs-devel@gnu.org; Wed, 08 Nov 2017 09:23:08 -0500 Original-Received: from ceres.etla.org ([2001:ba8:1f1:f1ef::2]:50046) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eCRFx-0005ve-1H for emacs-devel@gnu.org; Wed, 08 Nov 2017 09:23:05 -0500 Original-Received: from yaffle.pepperfish.net ([88.99.213.221] helo=[10.112.101.20]) by ceres.etla.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eCRFk-0003Io-2B; Wed, 08 Nov 2017 14:22:52 +0000 X-X-Sender: vivek@platypus.pepperfish.net In-Reply-To: X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "ceres.etla.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Wed, 8 Nov 2017, Stefan Monnier wrote: >> Won't they then be surprised by the normal value sanitisation/hook-firing > Hmm... what you say rings some kind of bell, but not clearly enough: > could give a scenario to clarify the issue? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:ba8:1f1:f1ef::2 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:219976 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1386749776-1510150980=:27794 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 8 Nov 2017, Stefan Monnier wrote: >> Won't they then be surprised by the normal value sanitisation/hook-firing > Hmm... what you say rings some kind of bell, but not clearly enough: > could give a scenario to clarify the issue? Sure, take something like glyphless-char-display-control which says: ========================================================================== Do not set its value directly from Lisp; the value takes effect only via a custom ‘:set’ function (‘update-glyphless-char-display’), which updates ‘glyphless-char-display’. You can customize this variable. ========================================================================== Or a variable which has a restricted set of possible values, as determined by its defcustom declaration... In the former case (or similar cases) the user might copy the setq and then be surprised that it does not work as expected. In the latter, they would copy the setq, alter the value (possibly to an "illegal" value) and then be surprised it didnt work. Maybe instead of setq a (users-will-copy-this-even-though-we-said-not-to …) form which _could_ be copied out of the custom-set-variables expression independently and would still trigger the relevant custom-related hooks and value-sanitisation (I believe someone suggested custom-set or similar instead of setq which might well do that). --8323329-1386749776-1510150980=:27794--