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] (Updated) Run hook when variable is set Date: Sun, 15 Feb 2015 15:25:52 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1424031987 20371 80.91.229.3 (15 Feb 2015 20:26:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 20:26:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kelly Dean Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 15 21:26:18 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 1YN5lh-00048j-RF for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 21:26:17 +0100 Original-Received: from localhost ([::1]:36514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN5lh-0000er-6m for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 15:26:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN5lZ-0000eW-MH for emacs-devel@gnu.org; Sun, 15 Feb 2015 15:26:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN5lU-0005Ku-LY for emacs-devel@gnu.org; Sun, 15 Feb 2015 15:26:09 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:38161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN5lU-0005Kp-Fr for emacs-devel@gnu.org; Sun, 15 Feb 2015 15:26:04 -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 t1FKQ1xR006459; Sun, 15 Feb 2015 15:26:02 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 4283E1637; Sun, 15 Feb 2015 15:25:52 -0500 (EST) In-Reply-To: (Kelly Dean's message of "Sat, 14 Feb 2015 22:19:45 +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 RV5218=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5218> : inlines <2184> : streams <1390817> : uri <1856081> 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:183120 Archived-At: >> It shouldn't either. This issue of which kind of advice to use is not >> specific to this variable, so there's no need to put it there. > It's an unusual function. I don't see why it should be special: it take the symbol that's about to be changed, its old/current value, and the candidate new value and returns the actual new value that should be used. Nothing special that I can see about that. > interaction with =C2=ABlet=C2=BB, and how to deal with the case of makunb= ound, all > need to be documented somewhere, Yes, handling unbound does require special care and needs to be documented, but it doesn't affect the way add-function is to be used. > and for completeness, it makes sense for the documentation to also > cover the case of not overriding the return value. How to override the value or block the assignment can be inferred from the above description. > If not in the docstring, then maybe in the manual? If you want to give examples, then indeed the manual would be a good place for it. >> Actually I don't see these as two independent elements combined >> into one. I see it as a single value with 3 levels: >> - any write you want >> - write vetted by Elisp code >> - no write at all > If there's just :before advice (e.g. a profiler), then the write is > not vetted. It is vetted, it's just that the vetting function decides not to always let things pass through. >> So far we've been extra careful to try and make sure Qunbound doesn't >> escape into Elisp world. I don't think we want to reconsider this >> design choice, since adding this Qunbound as a "normal" value in Elisp >> will just create the need for another special "really unbound" value. > Qunbound already escapes: you just have to use makunbound instead of =C2= =ABset=C2=BB > to set it, and boundp instead of symbol-value to read it. That doesn't let Qunbound escape. It gives you access to the concept and lets you control put (and check for) Qunbound in a symbol's `value' slot. But you don't actually get access to that value, so you can't store it in other slots of a symbol, or in a vector, list, ... > I've removed =C2=ABvoid=C2=BB. I recommend making makunbound stop working= on > non-globals too. `let' on dynamically-scoped variables doesn't make them non-local. Or rather, whether it does or not is a philosophical question (does `let' create a new variable which shadows the outer one, or does it just temporarily change the value of the variable?). Once you introduce multiple threads with shared memory, those threads get to test their theory, and usually it's considered that let-binding in that case should have only a thread-local effect, whereas the current implementation technique used in Emacs would naturally lead to the let-bindings having a global effect. >> - OLDVAL is either a list of one element containing the old value, or >> nil (when that old value is Qunbound). > Then run_varhook must cons. That'll generate a lot of garbage if you use = it > for profiling, or for debugging in a way where you don't just pause to > inspect every hooked variable. Is that ok? I think it's OK, yes. >> - Use a special value to represent "unbound", e.g. a special keyword like >> `::value--unbound::'. > (because it's impossible to set a hooked variable to that keyword), Yes, that's a disadvantage. > Or to avoid needing to cons in run_varhook, it could specbind something l= ike > Qsymbol_newval_void (to t if the new value is Qunbound), so the hook Yuck. That's even worse than using a value that is hopefully never used elsewhere, like `::value--unbound::'. > Would =E2=8C=9Cconst_hooked=E2=8C=9D be ok? How 'bout `writable' with values yes/no/thrufunction? Stefan