Re: WORG commit o-c/b/l/ob-doc-elisp.org: add new section on tangling and :var

Re: WORG commit o-c/b/l/ob-doc-elisp.org: add new section on tangling and :var

[Ihor Radchenko]

Hi,

I am looking at the commit
https://git.sr.ht/~bzg/worg/commit/1ba9e8397571da0e3297994b6f2c3518602c78e9
and wondering if it fits babel backend documentation scope.
It currently reads like a blog post describing some bug/design problem
with ob-emacs-lisp.

In a view of the problems you described, we might need to re-consider
ob-emacs-lisp handling within the scope of past discussion on using
let-binding in lisp-like babel backends. See
https://list.orgmode.org/orgmode/9eab60bc-9b82-e037-d63b-3d879573ae32@posteo.de/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: WORG commit o-c/b/l/ob-doc-elisp.org: add new section on tangling and :var

[Greg Minshall]

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