From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: sending function arguments to recursive function calls Date: Sat, 4 May 2013 08:30:39 -0700 Message-ID: <0F54256BD7B94384AC4DDA919D502C20@us.oracle.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1367681474 16825 80.91.229.3 (4 May 2013 15:31:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 May 2013 15:31:14 +0000 (UTC) To: "=?iso-8859-1?Q?'Gauthier_=D6stervall'?=" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat May 04 17:31:12 2013 Return-path: Envelope-to: geh-help-gnu-emacs@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 1UYeQV-0006t4-Sc for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2013 17:31:08 +0200 Original-Received: from localhost ([::1]:56350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYeQU-0007v7-UN for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2013 11:31:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYeQE-0007v1-C9 for help-gnu-emacs@gnu.org; Sat, 04 May 2013 11:30:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYeQC-0003zs-U4 for help-gnu-emacs@gnu.org; Sat, 04 May 2013 11:30:50 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:18917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYeQC-0003zb-H7 for help-gnu-emacs@gnu.org; Sat, 04 May 2013 11:30:48 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r44FUiBf006176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 May 2013 15:30:45 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r44FUhFB004437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 May 2013 15:30:44 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r44FUhEA005716; Sat, 4 May 2013 15:30:43 GMT Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 04 May 2013 08:30:43 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac5I1/7HPP2gljxASNSpZ0O8WCL4nAAAtUHg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:90471 Archived-At: > I am very new to e-lisp and lisp, and I expect the answer to my > question to be quite obvious when I see it. Newbie or not, you gave a great description of what you encountered. > I am puzzled by the function text-scale-adjust in lisp/face-remap.el. > The function takes (inc) as input parameter, and calls and passes this > (inc) to itself. Actually, it does not call itself. It sets up a keymap so that when you hit -, 0, or + it gets called again with (abs INC) as its arg. That's not the same thing as a recursive call. (But this is not relevant to the problem.) > If I copy this function to *scratch* and evaluate the defun with C-x > C-e, I expect not to have broken anything. What happens instead is > that the function's call to itself breaks. > The line (lambda () (interactive) (text-scale-adjust (abs inc)))))) > complains that inc is not defined: > "Symbol's value as variable is void: inc" > > If I return to the original function in face-remap.el and evaluate the > defun there again with C-x C-e, the function starts working again. > > What is the difference between the defun in face-remap.el, and its > copied version in *scratch*, that makes the propagation of inc work in > the first case but not in the second? > > I vaguely suspect it has to do with autoloads, but mainly because this > is what is most obscure to me at this point. Nope. Welcome to the joys of Emacs Lisp's way of mixing lexical and dynamic binding/scope. The key to the puzzle is this little declaration in the first comment of the file: ;;; face-remap.el --- Functions for ... -*- lexical-binding: t -*- That `lexical-binding t' tells Emacs that the code in this file is meant to be understood with the variable `lexical-binding' bound to t (locally). If you add and evaluate the following sexp to your *scratch* buffer then you will get the same effect as for the file: (set (make-local-variable 'lexical-binding) t) The problem was that the code you evaluated was not interpreted using lexical bindings, so the lambda form did not contain any environment for looking up the value of variable INC. An alternative to using a lexical binding here would be to simply use this: `(lambda () (interactive) (text-scale-adjust (abs ',inc))) That substitutes the value of INC from the initial call to `text-scale-adjust' into the lambda. So instead of there being a variable INC to look up there is a literal value (e.g. 2). Good question, BTW.