From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Inheriting some local variables from source code block editing buffers Date: Tue, 01 May 2018 21:53:44 +0100 Message-ID: <871sevayhz.fsf@gmail.com> References: <874ljt3bs0.fsf@gnu.org> <87h8nrkbpw.fsf@nicolasgoaziou.fr> <878t93ioa1.fsf@nicolasgoaziou.fr> <87bmdzbad6.fsf@gmail.com> <876047b257.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDcHX-0001wl-EJ for emacs-orgmode@gnu.org; Tue, 01 May 2018 16:53:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDcHU-0000fd-4M for emacs-orgmode@gnu.org; Tue, 01 May 2018 16:53:51 -0400 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:34900) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fDcHT-0000fP-U0 for emacs-orgmode@gnu.org; Tue, 01 May 2018 16:53:48 -0400 Received: by mail-wm0-x230.google.com with SMTP id o78so20862911wmg.0 for ; Tue, 01 May 2018 13:53:47 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: =?utf-8?B?R8O2a3R1xJ8=?= Kayaalp Cc: emacs-orgmode@gnu.org 2018ko maiatzak 1an, G=C3=B6ktu=C4=9F Kayaalp-ek idatzi zuen: >=20 > On 2018-05-01 20:35 +01, Aaron Ecay 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=E2=84= =A2 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. >=20 > 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=CA=BCt figure out then let us know. >=20 >> If lexical-binding is the major motivating factor, then maybe the above >> is enough. My original suggestion was for something like: >>=20 >> #+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val= )) >> ... >> #+end_src >>=20 >> This would set the variables in the edit buffer in the (hopefully) >> obvious way. It is not implemented yet, though. >=20 > 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. >=20 > -*- 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=CA=BCt be combined. AFAIR, :var is the only header argument that can be meaningfully specified more than once. --=20 Aaron Ecay