From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Run hook when variable is set Date: Thu, 29 Jan 2015 09:58:22 -0500 Message-ID: References: <7Dw4GTuMVOnntNGptSuTBkSMdmkHqNdTLkatZ8yKiM7@local> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422543534 31971 80.91.229.3 (29 Jan 2015 14:58:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 14:58:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kelly Dean Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 29 15:58:54 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YGqYV-0005Ne-J6 for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 15:58:51 +0100 Original-Received: from localhost ([::1]:60141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGqYV-00085z-4c for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 09:58:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGqY8-0007um-Iu for emacs-devel@gnu.org; Thu, 29 Jan 2015 09:58:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGqY4-00056o-Er for emacs-devel@gnu.org; Thu, 29 Jan 2015 09:58:28 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:36140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGqY4-00056f-5h for emacs-devel@gnu.org; Thu, 29 Jan 2015 09:58:24 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t0TEwMFC030869; Thu, 29 Jan 2015 09:58:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 1CBB42214; Thu, 29 Jan 2015 09:58:22 -0500 (EST) In-Reply-To: <7Dw4GTuMVOnntNGptSuTBkSMdmkHqNdTLkatZ8yKiM7@local> (Kelly Dean's message of "Thu, 29 Jan 2015 08:20:27 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5201=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5201> : inlines <1987> : streams <1381397> : uri <1844280> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181980 Archived-At: >> NACK from me. > Why? Just because of the slowdown for symbols that have property lists? For the same reason I want to kill the `intangible' text-property: this operates at too-low a level, so it's bound to introduce buggy interactions between unsuspecting packages. I like the idea of such hooks (which I've always thought of as "watchers" rather than hooks), actually, but only for purposes such as debugging. If we want to use such hooks for purposes such as "automatically recompute values of dependent vars", then I think the right way is to introduce a new layer which checks&runs these hooks, using the "raw" `setq' underneath. That's what I've done to add an "fset hook" (where the above layer which checks&runs the hook is `defalias'), but that was easy because the layering was pretty much already there. > I.e. if I eliminate the slowdown, then will you still have an > objection to the feature? Eliminating the slowdown is easy: extend the `constant' bit of variables to have 3 values: normal, read-only, and "hooked". This way normal vars are just as fast as before. But yes, I would still object to the use of such a low-level mechanism to solve your problem. > And I explained why your code doesn't provide a complete solution. > You didn't respond. I must have misunderstood or overlooked it. Can you retry? > Obviously, there are additional uses for this feature too. For just one > example, without varhook, what solution would you propose for bug #19068? For "a good solution" to bug#19068, we need to extend defcustom with dependency management, and then we need to tell people to use something else than `setq' (this something else will then be in charge of triggering the defcustom dependency management). Stefan