From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.help Subject: Re: [SOLVED with `eval']: Why I cannot use this variable in macro call from function? Date: Wed, 9 Jun 2021 08:51:29 +0200 Message-ID: <20210609065129.GB21706@tuxteam.de> References: <20210608183138.GA14693@tuxteam.de> <20210608200312.GE14693@tuxteam.de> <20210608202326.GG14693@tuxteam.de> <20210609060959.GA21706@tuxteam.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23567"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) To: Help GNU Emacs Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 09 08:52:06 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lqs4L-0005vF-Qj for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 09 Jun 2021 08:52:05 +0200 Original-Received: from localhost ([::1]:60512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqs4K-0007tR-Qp for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 09 Jun 2021 02:52:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57730) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqs3p-0007sw-L9 for help-gnu-emacs@gnu.org; Wed, 09 Jun 2021 02:51:33 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:39864) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1lqs3n-0005MJ-OI for help-gnu-emacs@gnu.org; Wed, 09 Jun 2021 02:51:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=5+0V98sYl0nBkSG2x0CTQjgh6uoDBJBklQKUTq1mbzs=; b=RscAT8GvVbOMroRn0SvhpxbYUs9NGlOBX0KveYUEQuxnvUErxHnR7ZmsS3IZ/7aNgOa2quFpXBcU2EgsPIehvB7qx95G7R/twpz1GhZaz9cFKQEIjnF+mzbcwsEHy7qqGKDUJllKd98R1U/6mygMo+/ApsOkluun28Cdqg404cbRiI0EZebFiJxKiLmAPphU/kOLp/iWFZ/I4cP67SmKynCdX3h7nM3zMRm02rHhhrKCn0ZWZ4SXQjQUTW8zjq5VRmNQM9fVUJn6HLljVygyJLppweoHKdQRqK+RpvQjaUvvb2MP1BZZmjp/2RYDt43F50qu/Nnhzx49oRDA9sBimQ==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1lqs3l-0006Yn-Qz for help-gnu-emacs@gnu.org; Wed, 09 Jun 2021 08:51:29 +0200 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:130653 Archived-At: --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 09, 2021 at 09:42:00AM +0300, Jean Louis wrote: > * tomas@tuxteam.de [2021-06-09 09:11]: > > You'll see "43" in your minibuffer. We managed to set the dynamically > > "defined" variable "that-other-var" to 43. Yay! Now enter > >=20 > > that-other-var > >=20 > > ...and again C-x e. Minibuffer says... 43. The variable escaped the > > scope. Bad variable, but hey, that's how setq goes, no? >=20 > Yes. I did it. >=20 > > * Experiment 2 > >=20 > > Make new lisp interaction buffer, as above. Make sure you have > > lexical binding (when experimenting, always change at most one > > thing at a time, right?). Now: > >=20 > > (let ((some-var 42) > > (that-other-var 44)) ; bind that-other-var locally > > (eval '(setq that-other-var 43)) > > (message "%S\n" that-other-var)) > >=20 > > Again, minibuffer says 43. Now... > >=20 > > that-other-var > >=20 > > ...and C-x e. What does minibuffer say? Is that right or wrong? > > Explain. >=20 > The one bound locally got 44, it was protected from a global > variable. That is so far expected. If I wish for example avoid case > sensitive entries, I do: Was "that-other-var" defined outside the `let'? If yes, what value did it have? If not, why not? [skipping the rest. I don't want even to think wrapping my head around all that before basic things are not cleared. You'll have to find yourself another sparring partner for this one, sorry] Cheers - t --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAmDAZPEACgkQBcgs9XrR2kYwmgCePJXaKCRERWWn/4tBkQSGBzC8 /jgAnRCq/vWX0Qjhs7vTRAh7zOGxNyU2 =G25o -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V--