From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tom Gillespie Newsgroups: gmane.emacs.devel Subject: [PATCH] hack-one-local-variable use lexical-binding Date: Wed, 25 Nov 2020 21:55:08 -0500 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000a100bb05b4f9ac5e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4462"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 26 03:56:42 2020 Return-path: Envelope-to: ged-emacs-devel@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 1ki7Sc-00014C-Pl for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Nov 2020 03:56:42 +0100 Original-Received: from localhost ([::1]:37164 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki7Sb-0001Qy-Od for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Nov 2020 21:56:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki7RL-0000ty-BU for emacs-devel@gnu.org; Wed, 25 Nov 2020 21:55:23 -0500 Original-Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]:38109) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ki7RJ-0002Ad-ES for emacs-devel@gnu.org; Wed, 25 Nov 2020 21:55:23 -0500 Original-Received: by mail-wr1-x444.google.com with SMTP id p8so483625wrx.5 for ; Wed, 25 Nov 2020 18:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UpCL6m/oeNiKDVQOciWj/lKlVMwe5nNbB9TNfpOHOic=; b=vX8VGU/xRZ49ErmBMrZVvN7zB/jVhht4urL89RbTiKea5eHpiTs55OBVQKpLAp3DOV tcnh0MeDEj+ZL3XcQULtcGULPp2wZCAaSwbT4FIrub0MSijeAEbq/tHyTLUCuwALnHFf O4Zo319k5ijexujo+oB4SP2nsRT1om3s9g/bqttmwFlIAZLRJJhCJlrDiDKZj1xNZ95z 5BFy7EvMdxVlAxWO62+lB90+F3uom5SUAHY4O08whibWvaypG9iuqC6aSD9eCPst9Hwn I8M6oK5p0OCXkCsmRNcCCWk/XmaEPYUyGLtDOvy4AlhEfiWDqAd7LFKtJFxapw4HgBrf w2xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UpCL6m/oeNiKDVQOciWj/lKlVMwe5nNbB9TNfpOHOic=; b=RnfgEB44WX+Rb0adkZumo6FTM9KJky/LGPadZwalpdl/Wqo6Eo6d7KsYAu0UQ17JPS j0HOkNLm+w1LQlCYqA15ve3EdtUj3Ml936iaMwY9p3Bzm00VPhdRU+jbshOI9R/0gMU7 1nqqiBEcn0YpGDyf9rApIkev82I+JWHJop9EFTKXb2xwC0Z8hAhwKLlcE7aAPbt1uqW0 dBwgUy3IYyGvmhRA79AvY9wS9CeTU0QQGaxgZV5EhxMTW+NDKUxjrVhbX8KJ/Xdap49B JPP2xSO/E1lzcuO7l+FLrD5BbTVbXsxgEtliLIxm4y7/+BwV0kl0uJmjWT0LGrR2jw5Q bceA== X-Gm-Message-State: AOAM5301Mc6HFihJrQb9zS7oyQmaj0XOGyRbijuIvhGSbNVGneIGfeJj 2q6UV/F6oeJYY5XlmRnsb0t5y5VJ+Nigd0veSF6LW/WjIG0= X-Google-Smtp-Source: ABdhPJxm+FriFwege/WrrVCDonNqGu4ydA92uvZkezejIsgyuEQDHPdmjj9YIyfmh4R1lNPQ9ZxKLsXyU3KkXWcUk8k= X-Received: by 2002:adf:916e:: with SMTP id j101mr1044265wrj.55.1606359319630; Wed, 25 Nov 2020 18:55:19 -0800 (PST) Received-SPF: pass client-ip=2a00:1450:4864:20::444; envelope-from=tgbugs@gmail.com; helo=mail-wr1-x444.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259820 Archived-At: --000000000000a100bb05b4f9ac5e Content-Type: text/plain; charset="UTF-8" Hi, A small patch with a long preamble and a few questions about the best approach. Best! Tom =eval:= local variables currently cannot use lexical-binding An example. #+begin_src org # -*- lexical-binding: t -*- ,#+name: code-block ,#+begin_src elisp :results none :lexical yes (setq testv "no") ,#+end_src Local Variables: eval: (let ((testv "yes")) (org-sbe code-block) (message "%s" testv)) End: #+end_src There are two possible solutions. One is to pass t as LEXICAL at all times. The other is to pass lexical-binding so that the behavior can be controlled via =-*- lexical-binding: t -*-= on the prop line. I'm not sure what the best approach is here. According to the manual https://www.gnu.org/software/emacs/manual/html_node/elisp/Using-Lexical-Binding.html other special evaluation contexts such as --eval, M-:, *scratch*, and *ielm* have all already switched over to lexical binding by default. Should local variables list eval variables follow the behavior of these other special execution contexts? Or, since they are part of a file should they follow the elisp file convention which is currently to follow the lexical-binding local variable? Despite personally having a use case for dynamic binding in this context, from a sanity point of view I think setting LEXICAL to t at all times may be the correct thing to do since with dynamic binding it is possible for a function to overwrite a let bound variable in such a way that the original value can never be recovered in the calling scope. However, that is sort of the point of dynamic binding, and it would be a major breaking change to the default behavior, and it would still not be configurable. Given that I also have no idea what the actual impact of that change would be on users, using the local value of lexical-binding seems to follow the principle of least surprise and seems to be future proof if the default value of lexical-binding is ever changed to t in the future (unlikely?). One impact of this change is that =-*- lexical-binding: t -*-= on the prop line will have meaning outside of Emacs lisp files and will have meaning in any file that makes use of an =eval:= local variable. As far as I can tell, passing =lexical-binding= works as expected. =lexical-binding= needs to be set on the prop-line as usual, but can also be set via an =eval:= local variable before any expression that needs lexical binding in the local variables list. This is probably ok because the use of =lexical-binding= in this context is not about the evaluation of the current file, but rather about the evaluation of further =eval:= local variables. Using =setq-local= to set =lexical-binding= to =nil= in the strange case where someone wants =lexical-binding= for their elisp file, but not when dealing with the =eval:= local variables is also possible. --000000000000a100bb05b4f9ac5e Content-Type: text/x-patch; charset="US-ASCII"; name="0001-hack-one-local-variable-use-lexical-binding.patch" Content-Disposition: attachment; filename="0001-hack-one-local-variable-use-lexical-binding.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_khy8s3v40 RnJvbSA1MjAxODkyNzc5NzM4Nzg3YTdkYmUyZDIyNzM1ZDJlZmI2MTY1OTdmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUb20gR2lsbGVzcGllIDx0Z2J1Z3NAZ21haWwuY29tPgpEYXRl OiBXZWQsIDI1IE5vdiAyMDIwIDIxOjM1OjA0IC0wNTAwClN1YmplY3Q6IFtQQVRDSF0gaGFjay1v bmUtbG9jYWwtdmFyaWFibGUgdXNlIGxleGljYWwtYmluZGluZwoKKiBsaXNwL2ZpbGVzLmVsICho YWNrLW9uZS1sb2NhbC12YXJpYWJsZSk6IHBhc3MgZXZhbCBsZXhpY2FsLWJpbmRpbmcKLS0tCiBs aXNwL2ZpbGVzLmVsIHwgMiArLQogMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRl bGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9maWxlcy5lbCBiL2xpc3AvZmlsZXMuZWwKaW5k ZXggNDljOWU1ZDE4ZC4uYzFjMThlYzU4ZCAxMDA2NDQKLS0tIGEvbGlzcC9maWxlcy5lbAorKysg Yi9saXNwL2ZpbGVzLmVsCkBAIC0zOTg0LDcgKzM5ODQsNyBAQCBoYWNrLW9uZS1sb2NhbC12YXJp YWJsZQogICAgICgnZXZhbAogICAgICAocGNhc2UgdmFsCiAgICAgICAgKGAoYWRkLWhvb2sgJyxo b29rIC4gLF8pIChoYWNrLW9uZS1sb2NhbC12YXJpYWJsZS0tb2Jzb2xldGUgaG9vaykpKQotICAg ICAoc2F2ZS1leGN1cnNpb24gKGV2YWwgdmFsKSkpCisgICAgIChzYXZlLWV4Y3Vyc2lvbiAoZXZh bCB2YWwgbGV4aWNhbC1iaW5kaW5nKSkpCiAgICAgKF8KICAgICAgKGhhY2stb25lLWxvY2FsLXZh cmlhYmxlLS1vYnNvbGV0ZSB2YXIpCiAgICAgIDs7IE1ha2Ugc3VyZSB0aGUgc3RyaW5nIGhhcyBu byB0ZXh0IHByb3BlcnRpZXMuCi0tIAoyLjI2LjIKCg== --000000000000a100bb05b4f9ac5e--