From: Greg Minshall <minshall@umich.edu>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: WORG commit o-c/b/l/ob-doc-elisp.org: add new section on tangling and :var
Date: Mon, 23 Sep 2024 12:28:01 +0300 [thread overview]
Message-ID: <287374.1727083681@archlinux> (raw)
In-Reply-To: <87r09bpr81.fsf@localhost>
hi, Ihor,
thanks for looking at my changes and for your e-mail.
i agree that the write-up is maybe a bit blog-post'y; i'm agnostic as to
whether it should be on that worg page or not. if anyone has some other
place to put it (on their own blog, where ever), feel free.
my memory is that of the two issues i mention, i see the lexical binding
as being a deficiency in org-mode tangle of elisp source code.
i.e., if the header argument =:lexical= is set to =yes=, then the
tangling process *should* insert the appropriate line:
----
;;; ... -*- lexical-binding: t -*-
----
as the first line of the tangled file. and, that *not* doing so is a
deficiency. or, at least it should do so in the case there are any
=:var= that are passed (which result in wrapping the user's code in a
let binding). (i'd probably opt for always doing it, when =:lexical= is
appropriately set; but that could also have some backwards compatibility
issues.)
the other issue, which i guess resonates with the mailing list from last
year you pointed me at
----
https://list.orgmode.org/orgmode/9eab60bc-9b82-e037-d63b-3d879573ae32@posteo.de/
----
where there are problems because =(require...)= (=(import...)= for that
discussion, i think?) is not at the top level of the tangled source file
is harder, i would guess. as the discussion pointed out, for elisp, we
evaluate the code in the currently running Emacs process. (namespaces,
namespaces, namespaces...)
am i right, though, that in the *absence* of a =:var=, any =defun=,
=defvar=, maybe any globally-scoped =setq=, are all polluting
("enhancing" should you prefer) the global name space?
----
#+begin_src elisp
(setq fubart 33)
(defvar fubary "and then left")
(defun fubar () (message "%d-year old kilroy was here (%s)" fubart fubary))
#+end_src
----
so, maybe the =:var= doesn't add that much (to an already-dubious
situation; sometimes you want that, sometimes you don't).
(the fact that this only increases the "problem" "slightly" reminds one
of the straw that broke the camel's back. :)
as someone -- you? -- often says, WDYT?
again, thanks.
cheers, Greg
prev parent reply other threads:[~2024-09-23 9:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-22 16:50 WORG commit o-c/b/l/ob-doc-elisp.org: add new section on tangling and :var Ihor Radchenko
2024-09-23 9:28 ` Greg Minshall [this message]
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=287374.1727083681@archlinux \
--to=minshall@umich.edu \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).