2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen: > > On 2018-05-01 20:35 +01, Aaron Ecay <aarone...@gmail.com> wrote: >> Thinking about it some more, lexical binding is not a good case for >> this feature, since it has to be set not only in the edit buffer, but >> also when C-c C-c is used in the org-mode buffer to evaluate the src >> block. The :lexical header arg (which I did not know about) works for >> the latter but not the former. To complete the picture, Someone™ needs >> to implement a org-babel-edit-prep:emacs-lisp function which looks for >> :lexical yes in the header arguments and sets the value in the edit >> buffer appropriately. > > I can (and plan to) take on that task once a design is agreed upon. I > don't really know much about Org internals, but I think I can figure > out.
That is excellent news :) If you run into anything you canʼt figure out then let us know. > >> If lexical-binding is the major motivating factor, then maybe the above >> is enough. My original suggestion was for something like: >> >> #+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val)) >> ... >> #+end_src >> >> This would set the variables in the edit buffer in the (hopefully) >> obvious way. It is not implemented yet, though. > > I do like that syntax. A minor addition might be for the case when one > wants to pass the value of a variable local to the org buffer to the > editing buffer: That looks fine to me. > > -*- fill-column: 65; indent-tabs-mode: nil -*- > #+edit-vars: (indent-tabs-mode) A minor note, the above line should read: #+header: :edit-vars (indent-tabs-mode) > #+begin_src emacs-lisp :edit-vars (fill-column (lexical-binding t)) But because of the nature of the variable (a lisp list), it can only be set once. So you can have only one of: #+header :edit-vars ... OR #+begin_src emacs-lisp :edit-vars ... OR #+property: header-args:emacs-lisp :edit-vars ... OR :PROPERTIES: :header-args:emacs-lisp: :edit-vars ... :END: But they canʼt be combined. AFAIR, :var is the only header argument that can be meaningfully specified more than once. -- Aaron Ecay
