all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Gauthier Östervall'" <gauthier@ostervall.se>, help-gnu-emacs@gnu.org
Subject: RE: sending function arguments to recursive function calls
Date: Sat, 4 May 2013 08:30:39 -0700	[thread overview]
Message-ID: <0F54256BD7B94384AC4DDA919D502C20@us.oracle.com> (raw)
In-Reply-To: <CAM8gEgi34z677SUCJ8d=Ajo3jKTq0_JYjcpH+rxY5s2B0YTmOA@mail.gmail.com>

> 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.




  reply	other threads:[~2013-05-04 15:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-04 13:01 sending function arguments to recursive function calls Gauthier Östervall
2013-05-04 15:30 ` Drew Adams [this message]
2013-05-07 11:25   ` Gauthier Östervall
2013-05-07 14:04     ` Drew Adams
2013-05-08 12:21       ` Stefan Monnier
2013-05-09  8:35         ` Gauthier Östervall
2013-05-09 12:23           ` Stefan Monnier
2013-05-12 13:19             ` Gauthier Östervall
2013-05-13 14:55               ` Stefan Monnier
2013-05-17 12:20                 ` Gauthier Östervall
2013-05-17 12:26                   ` Dmitry Gutov
2013-05-17 14:31                     ` Drew Adams
2013-05-19 16:57                       ` Dmitry Gutov
2013-05-21 16:34                         ` Drew Adams
     [not found]                       ` <mailman.70.1368982677.22516.help-gnu-emacs@gnu.org>
2013-05-19 20:59                         ` Pascal J. Bourguignon
2013-05-20 19:31                           ` Dmitry Gutov
     [not found]                           ` <mailman.94.1369078320.22516.help-gnu-emacs@gnu.org>
2013-05-20 19:55                             ` Pascal J. Bourguignon
2013-05-07 14:32     ` Pascal J. Bourguignon
     [not found]     ` <mailman.25279.1367935468.855.help-gnu-emacs@gnu.org>
2013-05-07 14:55       ` Pascal J. Bourguignon
2013-05-08 12:25         ` Stefan Monnier
2013-05-05  1:22 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0F54256BD7B94384AC4DDA919D502C20@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=gauthier@ostervall.se \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.