From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Using "Emacs Configure" **and** modifying .emacs Date: Fri, 11 Aug 2017 13:46:31 -0700 (PDT) Message-ID: References: <1502373086.1171866.1069247696.71F9FED4@webmail.messagingengine.com> <8660dvuzsr.fsf@zoho.com> <1502436066.2568371.1070085968.1D25E0E7@webmail.messagingengine.com> <87tw1ekxgo.fsf@127.0.0.1> <867ey9sva2.fsf@zoho.com> 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 1502484437 19452 195.159.176.226 (11 Aug 2017 20:47:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 11 Aug 2017 20:47:17 +0000 (UTC) To: Emanuel Berg , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 11 22:47:08 2017 Return-path: Envelope-to: geh-help-gnu-emacs@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 1dgGpi-0004Bt-CI for geh-help-gnu-emacs@m.gmane.org; Fri, 11 Aug 2017 22:47:02 +0200 Original-Received: from localhost ([::1]:46591 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgGpo-000736-HX for geh-help-gnu-emacs@m.gmane.org; Fri, 11 Aug 2017 16:47:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgGpL-00072M-Uo for help-gnu-emacs@gnu.org; Fri, 11 Aug 2017 16:46:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgGpI-0001l8-P9 for help-gnu-emacs@gnu.org; Fri, 11 Aug 2017 16:46:40 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:19734) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dgGpI-0001k7-Cw for help-gnu-emacs@gnu.org; Fri, 11 Aug 2017 16:46:36 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7BKkX41013389 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Aug 2017 20:46:33 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v7BKkXdr003226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Aug 2017 20:46:33 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7BKkWwT031334; Fri, 11 Aug 2017 20:46:32 GMT In-Reply-To: <867ey9sva2.fsf@zoho.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6774.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:113996 Archived-At: > > There are some custom settings (I'm afraid > > I can think of anything specific at the > > moment) where setting them via > > `customize-...' also triggers a setting up > > function, which incorporates the new setting > > into something deeper than just > > a variable value. >=20 > Let's see: a variable that triggers a function > when it (the variable) is set, only that only > works when it is set with a specific function? >=20 > And what happens if the variable is the the > old-fashion way? An inconsistent state as there > is now a mismatch between the variable value > and the un-triggered function? >=20 > Well, hell. In my experience, bad ideas can't > be circumvent by dealing with them the > supposedly right way. That can only prolong the > time before you realize it is a bad idea. Yes, it is perhaps unfortunate that there is not a more pervasive way to detect setting and thus trigger application of the `:set' function. On the other hand, this is Lisp, which means that code can be generated and evaluated later etc., and it might sometimes not be correct to trigger the function - at least one can imagine that one size does not fit all situations. Still, I think we could improve things in this regard. Perhaps by a symbol property that is checked when the variable is set in any way (e.g. including by `set' and `setq'). And perhaps by checking that some other property or variable value does not override that automatic set-triggering behavior. Dunno. But the lesson _here_ is simply that this is the way things are, and it behooves a Lisp users to be aware of it. If you don't want to get bit then it is a good idea to "deal with them the supposedly right way." And that's not hard to do: just use `customize-variable' instead of `setq', for user options. How hard is that? If you want something shorter, define an alias...