Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

Hi Göktuğ,

A couple of comments:

2018ko maiatzak 18an, Göktuğ Kayaalp-ek idatzi zuen:

[...]

> +(defcustom org-src-apply-risky-edit-bindings 'ask
> +  "What to do if an edit binding is a risky local variable.
> +If this is nil, bindings that satisfy ‘risky-local-variable-p’
> +are skipped, with a warning message.  Otherwise, its value should
> +be a symbol telling how to thread them.  Possible values of this
> +setting are:
> +
> +nil  Skip, warning the user via a message.
> +skip-silent  Skip risky local varibles silently.
> +ask  Prompt user for each variable.
> +tApply the variable but show a warning.
> +apply-silent Apply risky local variables silently."

It would be more consistent/less confusing to use skip-warn and
apply-warn instead of nil and t.  It would also lead to fewer bugs in
the sense that:

[...]

> +(cond ((or (and (eq org-src-apply-risky-edit-bindings 'ask)
> +(y-or-n-p (format prompt-apply name value)))
> +   (eq org-src-apply-risky-edit-bindings 'apply-silent))
> +   (funcall apply-binding))
> +  (org-src-apply-risky-edit-bindings
> +   (prog1
> +   (funcall apply-binding)
> + (message risky-message "Applied" name)))
> +  ((not org-src-apply-risky-edit-bindings)
> +   (message risky-message "Skipped" name))
> +  ((eq org-src-apply-risky-edit-bindings 'skip-silent))
> +  ('else
> +   (user-error
> +"Unexpected value for ‘%S’, will not apply this or any more 
> bindings."
> +'org-src-apply-risky-edit-bindings

If I am reading the above cond correctly, then the (eq
org-src-apply-risky-edit-bindings 'skip-silent) branch will never be
reached, because it will be eaten by the second branch.  (And so will
the “else” branch, for that matter.)

IMO you should use cl-case instead of cond, which will be less conducive
to subtle problems like this and make it clear that the possible values
are exhaustively handled.  (That approach will mean shuffling the y-or-n-p
stuff around slightly).

[...]

> +(defun org-src--parse-edit-bindings (sexp-str pos-beg pos-end)
> +  ;; XXX: require cadr of the varlist items to be atoms, for security?
> +  ;; Or prompt users?  Because otherwise there can be complete
> +  ;; programs embedded in there.

Maybe instead of using risky-local-variable-p above, this feature should
use safe-local-variable-p instead.  Then we wouldnʼt have to worry about
the security implications of allowing non-atom values.  It seems like a
version of this feature that only worked for atoms would be quite limited
in functionality.  In that case, we should probably call the defcustom
above ...apply-unsafe-edit-bindings for the sake of accuracy.

-- 
Aaron Ecay

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Hello,

Göktuğ Kayaalp  writes:

> And here it is.  Please find the patch attached.

Thank you. Comments follow.

> I have ran the entire test suite against this, which completed w/
> 6 failures, seemingly unrelated (they fail on revision 58c9bedfd too);

You may be using an old revision. I see no error from tests in HEAD.

> find the list below. I have tried to follow apparent conventions in
> each file w.r.t. the copyright/authors lines, sorry if I modified them
> unnecessarily.

Usually, we do not modify authors lines, which represents the people who
initially wrote the file. No worries, though.

> Subject: [PATCH] Implement edit bindings feature
>
> Enable defining local variable bindings to be applied when editing
> source code.
>
> * lisp/org-src.el (org-src--apply-edit-bindings)
> (org-src--simplify-edit-bindings)
> (org-src--parse-edit-bindings)
> (org-src--edit-bindings-string)
> (org-src--get-edit-bindings-for-subtree)
> (org-src--get-edit-bindings-from-header)
> (org-src--collect-global-edit-bindings)
> (org-src--collect-edit-bindings-for-element): New functions.
> (org-src-apply-risky-edit-bindings): New defcustom.
> (org-src--edit-element):
> * doc/org.texi (Editing source code): Add edit bindings.

"org.texi" no longer exists in master. We write the manual as an Org
file: "org-manual.org".

> +It is possible to define local variable bindings for these buffers using the
> +@samp{edit-bindings} element header, the @samp{edit-bindings} buffer
> +property, or the @samp{EDIT_BINDINGS} entry property.  All three can be used
> +together, the bindings from the header override those of the subtree, and
> +they both override the bindings from buffer properties.  The syntax is
> +similar to that of @code{let} varlists, but a sole symbol means the
> +variable's value is copied from the Org mode buffer.  Multiple uses of
> +@samp{edit-bindings} headers and buffer properties are supported, and works
> +like @code{let*}.  Entry property @samp{EDIT_BINDINGS} can not be repeated.
> +Below is an example:

It seems you are partly re-inventing the wheel here. Org already has
such mechanism, called Babel headers:

#+PROPERTY: header-args :edit-bindings '(...)

:PROPERTIES:
:HEADER-ARGS: :edit-bindings '(...)
:END:

#+header: :edit-bindings '(...)
...

Of course, this is currently limited to source blocks and inline source
blocks. However, I think it is better to extend them to your use-case
than rewriting something different, albeit similar.

You already looked at `org-babel-get-src-block-info'. You may want to
start hacking on it and extend it instead of providing your own tools.

>  ** New features
> +*** Set local variables for editing blocks
> +Bindings from =edit-bindings= header and buffer property, and
> +=EDIT_BINDINGS= entry property are applied in Org Src buffers.  For
> +example, when editing the following code block with
> +~org-edit-special~:

AFAIU, these bindings are not used when evaluating the buffer, which may
be surprising. What about calling them :local-bindings instead
of :edit-bindings and handle them in Babel too?

In this case, what would be the difference with, e.g., 

:var lexical-binding=t

> +(defun org-src--apply-edit-bindings (simplified-bindings)

Could you provide a docstring for the functions?

> +  (pcase-dolist (`(,name . ,value) simplified-bindings)
> +(let ((prompt-apply
> +(concat "Setting risky local variable ‘%S’"
> +" in edit-special buffer, its value is: %S; Continue?"))

You can use \ + \n, i.e., continuation string instead of calling
`concat' each time.

> +   (risky-message "%s risky local variable ‘%S’ in edit-special buffer.")

I suggest to use two different messages instead of doing the above, if
one day we move to proper i18n.

> +   (apply-binding (lambda () (set (make-local-variable name)
> +  (eval value)
> +  (unless
> +   (and
> +(risky-local-variable-p name)
> +(cond ((or (and (eq org-src-apply-risky-edit-bindings 'ask)
> +(y-or-n-p (format prompt-apply name value)))
> +   (eq org-src-apply-risky-edit-bindings 'apply-silent))
> +   (funcall apply-binding))
> +  (org-src-apply-risky-edit-bindings
> +   (prog1
> +   (funcall apply-binding)
> + (message risky-message "Applied" name)))

You probably mean

  (funcall apply-binding)
  (message ...)
  t

which is clearer, IMO.

> +  ((not org-src-apply-risky-edit-bindings)
> +   (message risky-message "Skipped" name))
> +  ((eq org-src-apply-risky-edit-bindings 'skip-silent))
> +  ('else
> +   (user-error
> +"Unexpected value for ‘%S’, will not apply this or any more 
> bindings."
> +'org-src-apply-risky-edit-bindings

Error messages must not end with a period.

> + 

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-15 21:36 +03, Göktuğ Kayaalp  wrote:
> So, today I've started implementing a version of this that works like
> this:
>
> #+begin_example
>   #+property: edit-bindings /varlist/
>   * heading
>   :properties:
>   :edit_bindings: /varlist/
>   :end:
>   #+header: edit-bindings /varlist/
> #+end_example
>
>
> where scoping is like (x > y meaning x overrides y):
>
>   header line bindings > subtree bindings > #+property bindings before
>   the element
>
> I'll send a complete patch soon.

And here it is.  Please find the patch attached.  I have ran the entire
test suite against this, which completed w/ 6 failures, seemingly
unrelated (they fail on revision 58c9bedfd too); find the list below.  I
have tried to follow apparent conventions in each file w.r.t. the
copyright/authors lines, sorry if I modified them unnecessarily.

6 unexpected results:
   FAILED  test-ob/org-babel-remove-result--results-list
   FAILED  test-org-clock/clocktable/step
   FAILED  test-org/add-planning-info
   FAILED  test-org/clone-with-time-shift
   FAILED  test-org/deadline
   FAILED  test-org/schedule

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

>From b6d2b60730ceed68f46ef839c486e03764defdc7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C4=B0=2E=20G=C3=B6ktu=C4=9F=20Kayaalp?= 
Date: Tue, 15 May 2018 20:34:28 +0300
Subject: [PATCH] Implement edit bindings feature

Enable defining local variable bindings to be applied when editing
source code.

* lisp/org-src.el (org-src--apply-edit-bindings)
(org-src--simplify-edit-bindings)
(org-src--parse-edit-bindings)
(org-src--edit-bindings-string)
(org-src--get-edit-bindings-for-subtree)
(org-src--get-edit-bindings-from-header)
(org-src--collect-global-edit-bindings)
(org-src--collect-edit-bindings-for-element): New functions.
(org-src-apply-risky-edit-bindings): New defcustom.
(org-src--edit-element):
* doc/org.texi (Editing source code): Add edit bindings.

* testing/lisp/test-org-src.el (test-org-src/edit-bindings-parser)
(test-org-src/collect-edit-bindings-for-element)
(test-org-src/edit-bindings-precedence-and-application)
(test-org-src/edit-bindings-use-cases): Add relevant tests.
---
 doc/org.texi |  43 +
 etc/ORG-NEWS |  15 +++
 lisp/org-src.el  | 223 +++
 testing/lisp/test-org-src.el | 172 -
 4 files changed, 436 insertions(+), 17 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 6aab1ba4e..c588152fd 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -15364,6 +15364,7 @@ Source code in the dialect of the specified language identifier.
 
 @vindex org-edit-src-auto-save-idle-delay
 @vindex org-edit-src-turn-on-auto-save
+@vindex org-src-apply-risky-edit-bindings
 @kindex C-c '
 @kbd{C-c '} for editing the current code block.  It opens a new major-mode
 edit buffer containing the body of the @samp{src} code block, ready for any
@@ -15421,6 +15422,48 @@ Emacs-Lisp languages.
 ("python" (:background "#E5FFB8"
 @end lisp
 
+It is possible to define local variable bindings for these buffers using the
+@samp{edit-bindings} element header, the @samp{edit-bindings} buffer
+property, or the @samp{EDIT_BINDINGS} entry property.  All three can be used
+together, the bindings from the header override those of the subtree, and
+they both override the bindings from buffer properties.  The syntax is
+similar to that of @code{let} varlists, but a sole symbol means the
+variable's value is copied from the Org mode buffer.  Multiple uses of
+@samp{edit-bindings} headers and buffer properties are supported, and works
+like @code{let*}.  Entry property @samp{EDIT_BINDINGS} can not be repeated.
+Below is an example:
+
+@example
+# -*- fill-column: 65 -*-
+#+PROPERTY: edit-bindings '(fill-column (lexical-binding t))
+
+* Example section
+:PROPERTIES:
+:EDIT_BINDINGS: '((emacs-lisp-docstring-fill-column 60))
+:END:
+
+#+HEADER: edit-bindings '((lexical-binding nil))
+#+BEGIN_SRC elisp
+(defun hello ()
+  (message "Hello world!"))
+#+END_SRC
+
+* Another section
+#+BEGIN_SRC elisp
+(defun hello ()
+  (message "Byes world!"))
+#+END_SRC
+@end example
+
+In this example, when editing the first block, @code{lexical-binding} will be
+@code{nil}, and @code{emacs-lisp-docstring-fill-column} 60.  With the second
+one, they will be @code{t} and the variable's default value, respectively.
+@code{fill-column} will be 65 for both.
+
+Set @code{org-src-apply-risky-edit-bindings} for how risky local variables in
+these bindings are handled.  The default behaviour is to ask to the user
+whether or not to apply them.
+
 @node Exporting code blocks
 @section Exporting code blocks
 @cindex code block, exporting
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 21eaaece6..879240f31 100644
--- a/etc/ORG-NEWS
+++ 

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-14 18:47 +02, Nicolas Goaziou  wrote:
> (org-element-property :header (org-element-at-point)) => (":foo bar")
[...]
>> I can't find any documentation on Org-mode's internal APIs and how
>> different parts fit together, so I'm having to figure things out reading
>> source code.
>
> See .

Thanks, and sorry.  I've been mostly ignoring Worg up until now, because
I haven't seen the worg/dev/ pages mentioned in the info manual (I'd
expect to see those pages mentioned in the Hacking section BTW, I can
send a patch mentioning them in a "Further resources" subsection there
if you'd like that added).

So, today I've started implementing a version of this that works like
this:

#+begin_example
  #+property: edit-bindings /varlist/
  * heading
  :properties:
  :edit_bindings: /varlist/
  :end:
  #+header: edit-bindings /varlist/
#+end_example


where scoping is like (x > y meaning x overrides y):

  header line bindings > subtree bindings > #+property bindings before
  the element

I'll send a complete patch soon.

Best,

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-14 14:33 +01, Aaron Ecay  wrote:
> Hi Göktuğ,
>
> This patch looks good, thanks.  Of course, for merging to org core it
> will need to be an actual patch and not advice.

Certainly; this is meant as a ‘tangible’ example, and can easily be
turned into a patch if you want to merge this.

> There is also copyright
> assignment to think of.  Do you already have a FSF copyright assignment
> on file?

I have signed the assignment for GNU Emacs, and contributed a couple
patches.  IDK if that can be reused here though, but if not I can do the
paperwork again.

> 2018ko maiatzak 14an, Göktuğ Kayaalp-ek idatzi zuen:
>
> [...]
>
>> One ‘gotcha’ is that :edit-bindings requires a quoted list whereas the
>> explicit quote is not necessary with ATTR_EDIT:
>> 
>> #+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
>> #+ATTR_EDIT: ((lexical-binding t))
>
> That quote is required for the src block version is inherent in the
> design of babel.  For consistency, you could require (or at least permit
> without requiring) a quote in the other case as well.

I guess requiring that would be better given it can cause confusion if
it works one way but not the other.

> I think you could replace the (let (var val)...) form with:
>
> #+begin_src emacs-lisp
>   (pcase-dolist ((or (and (pred symbolp) var
>   (let val (buffer-local-value var source-buffer)))
>  `(,var ,val))
>  varlist)
> (set (make-local-variable var) val))
> #+end_src
>
> This silently skips varlist entries that are of the wrong shape, but it
> would be possible to make it raise an error as in your version.  I like
> the pcase version better because itʼs shorter and has fewer nested
> conditionals, but itʼs ultimately a matter of taste.

Yeah I can integrate this.  I was initially going to use pcase, but I
can't understand how it works for the life of me.  It's one of the two
lisp macros together with loop that I can't get my head around.

So, I will turn this into a patch, make the change regarding the initial
quote, use pcase, and see how Nicolas responds to me about the
#+ATTR_EDIT.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Göktuğ Kayaalp  writes:

> The attr was meant for BEGIN_EXPORT blocks because it seems to me that
> an equivalent of ‘org-babel-get-src-block-info’ does not exist for those
> blocks, and that function _only_ works with BEGIN_SRC blocks.  Is there
> a function available or would I have to write one to do this?

With the following example:

   #+header: :foo bar
   #+begin_export latex
   Foo
   #+end_export

(org-element-property :header (org-element-at-point)) => (":foo bar")

and

(cl-mapcan #'org-babel-parse-header-arguments
   (org-element-property :header (org-element-at-point)))

=>

((:foo . "bar"))


> Looking all over the Org manual searching for BEGIN_(LATEX|HTML), I
> haven't seen once a header argument used with a block that is not a
> BEGIN_SRC block, in neither of the forms.  And none of the ‘org-edit-*’
> functions apart from ‘org-edit-src-code’ in org-src.el seem to process
> header arguments, and nor does ‘org-src--edit-element’.

True, but this is also true for "attr_...".

> I can't find any documentation on Org-mode's internal APIs and how
> different parts fit together, so I'm having to figure things out reading
> source code.

See .

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-14 14:13 +02, Nicolas Goaziou  wrote:
> You shouldn't add another "attr" keyword, which is reserved for export
> back-ends. Actually, every Babel header can be located either on the
> block opening line, e.g.,
>
> #+begin_src emacs-lisp :some-property some-value
>
> or as an affiliated #+header: keyword, e.g.,
>
> #+header: :some-property some-value
> #+begin_src emacs-lisp
>
>
> Note that "#+header:" keywords are supported everywhere, without
> modifying the parser, e.g.,
>
> #+header: :some-property some-value
> A paragraph.

The attr was meant for BEGIN_EXPORT blocks because it seems to me that
an equivalent of ‘org-babel-get-src-block-info’ does not exist for those
blocks, and that function _only_ works with BEGIN_SRC blocks.  Is there
a function available or would I have to write one to do this?

Looking all over the Org manual searching for BEGIN_(LATEX|HTML), I
haven't seen once a header argument used with a block that is not a
BEGIN_SRC block, in neither of the forms.  And none of the ‘org-edit-*’
functions apart from ‘org-edit-src-code’ in org-src.el seem to process
header arguments, and nor does ‘org-src--edit-element’.

I can't find any documentation on Org-mode's internal APIs and how
different parts fit together, so I'm having to figure things out reading
source code.

The following form returns nil for the following examples:

(plist-get :header (cadr (org-element-at-point))) ;=> nil

(cl-remove-if-not #'symbolp (cadr (org-element-at-point)))
  ;=> (:type :begin :end :value :post-blank :post-affiliated :header
   :parent nil)

#+header: :edit-bindings '((lexical-binding t))
#+BEGIN_EXPORT latex
#+END_EXPORT

#+BEGIN_EXPORT latex :edit-bindings '((lexical-binding t))
#+END_EXPORT

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
#+END_SRC

#+header: :edit-bindings '((lexical-binding t))
#+BEGIN_SRC elisp
#+END_SRC

> Also, for integration in Org mode proper, some testing would be more
> than welcome

If this feature will be included upstream, I can make this into a patch
instead of an advice and add the related docs and tests.  This was meant
as a concrete example of the concept.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

Hi Göktuğ,

This patch looks good, thanks.  Of course, for merging to org core it
will need to be an actual patch and not advice.  There is also copyright
assignment to think of.  Do you already have a FSF copyright assignment
on file?

2018ko maiatzak 14an, Göktuğ Kayaalp-ek idatzi zuen:

[...]

> One ‘gotcha’ is that :edit-bindings requires a quoted list whereas the
> explicit quote is not necessary with ATTR_EDIT:
> 
> #+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
> #+ATTR_EDIT: ((lexical-binding t))

That quote is required for the src block version is inherent in the
design of babel.  For consistency, you could require (or at least permit
without requiring) a quote in the other case as well.

> 
> Another problem is that I was not able to define a new element property
> named EDIT_BINDINGS, and had to take the shortcut with naming it as an
> ATTR_* variable.  Preferably, it'd be EDIT_BINDINGS instead:
> 
> #+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
> #+EDIT_BINDINGS: ((lexical-binding t))
> 
> But personally I don't think it's that big of a problem.
> 
> 
> The advice:
> 
> (define-advice org-src--edit-element
> (:around
>  (fn datum  args)
>  attr-edit)
>   "Apply edit-special bindings."
>   (let ((attr-edit (org-element-property :attr_edit datum))
> (edit-bindings
>  (assoc :edit-bindings (caddr (org-babel-get-src-block-info nil 
> datum
> (source-buffer (current-buffer))
> (sub (lambda (varlist source-buffer)
>(let (var val)
>  (dolist (form varlist)
>;; If it's a symbol, inherit from the Org mode buffer.
>(if (symbolp form)
>(setq var form
>  val (with-current-buffer source-buffer (eval 
> var)))
>  ;; Else, apply the specified value.
>  (setq var (car form) val (cadr form)))
>(unless (symbolp var)
>  ;; XXX: maybe tell where it is?
>  (user-error "Bad varlist at ATTR_EDIT"))
>(set (make-local-variable var) val))

I think you could replace the (let (var val)...) form with:

#+begin_src emacs-lisp
  (pcase-dolist ((or (and (pred symbolp) var
  (let val (buffer-local-value var source-buffer)))
 `(,var ,val))
 varlist)
(set (make-local-variable var) val))
#+end_src

This silently skips varlist entries that are of the wrong shape, but it
would be possible to make it raise an error as in your version.  I like
the pcase version better because itʼs shorter and has fewer nested
conditionals, but itʼs ultimately a matter of taste.

-- 
Aaron Ecay

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Hello,

Göktuğ Kayaalp  writes:

> Sorry for the silence, I've finally got around to implementing this, and
> implemented it as an advice, which supports both an ‘:edit-bindings’
> Babel header argument for source code blocks, and an #+ATTR_EDIT:
> element property for export blocks, etc.  Find the code below, and
> attached an Org mode file to help with testing.

Thank you. Some comments follow.

You shouldn't add another "attr" keyword, which is reserved for export
back-ends. Actually, every Babel header can be located either on the
block opening line, e.g.,

#+begin_src emacs-lisp :some-property some-value

or as an affiliated #+header: keyword, e.g.,

#+header: :some-property some-value
#+begin_src emacs-lisp

Note that "#+header:" keywords are supported everywhere, without
modifying the parser, e.g.,

#+header: :some-property some-value
A paragraph.

Also, for integration in Org mode proper, some testing would be more
than welcome

Regards,

-- 
Nicolas Goaziou

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

Hello,

Sorry for the silence, I've finally got around to implementing this, and
implemented it as an advice, which supports both an ‘:edit-bindings’
Babel header argument for source code blocks, and an #+ATTR_EDIT:
element property for export blocks, etc.  Find the code below, and
attached an Org mode file to help with testing.

This advice can easily be made into a patch to the
‘org-src--edit-element’ function.

One ‘gotcha’ is that :edit-bindings requires a quoted list whereas the
explicit quote is not necessary with ATTR_EDIT:

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
#+ATTR_EDIT: ((lexical-binding t))

Another problem is that I was not able to define a new element property
named EDIT_BINDINGS, and had to take the shortcut with naming it as an
ATTR_* variable.  Preferably, it'd be EDIT_BINDINGS instead:

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
#+EDIT_BINDINGS: ((lexical-binding t))

But personally I don't think it's that big of a problem.


The advice:

(define-advice org-src--edit-element
(:around
 (fn datum  args)
 attr-edit)
  "Apply edit-special bindings."
  (let ((attr-edit (org-element-property :attr_edit datum))
(edit-bindings
 (assoc :edit-bindings (caddr (org-babel-get-src-block-info nil 
datum
(source-buffer (current-buffer))
(sub (lambda (varlist source-buffer)
   (let (var val)
 (dolist (form varlist)
   ;; If it's a symbol, inherit from the Org mode buffer.
   (if (symbolp form)
   (setq var form
 val (with-current-buffer source-buffer (eval var)))
 ;; Else, apply the specified value.
 (setq var (car form) val (cadr form)))
   (unless (symbolp var)
 ;; XXX: maybe tell where it is?
 (user-error "Bad varlist at ATTR_EDIT"))
   (set (make-local-variable var) val))

;; Apply function
(apply fn datum args)

;; Apply edit attributes (ATTR_EDIT).
(dolist (attr attr-edit)
  (let ((varlist (car (read-from-string attr
(unless (listp varlist)
  (user-error "Value of ATTR_EDIT must be a varlist."))
(funcall sub varlist source-buffer)))
;; Apply edit bindings (:edit-bindings header argument).
;; These override attr-edit values.
(when edit-bindings
  (funcall sub (cdr edit-bindings) source-buffer

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

# $Id: edit-bindings.org,v 1.2 2018/05/14 05:23:48 g Exp $
#+title: :edit-bindings and #+ATTR_EDIT test file
#+author: Göktuğ Kayaalp

We use the variables ~lexical-binding~, ~truncate-lines~ and
~word-wrap~ for this test/demo.  We assume the first is ~nil~, the
second is set from a file local variable, and for the third we have no
assumptions.

#+BEGIN_SRC elisp :results verbatim
(list lexical-binding truncate-lines word-wrap)
#+END_SRC

#+RESULTS:
: (nil 62 t)

Now we set up the default ~:edit-bindings~ property.

#+PROPERTY: header-args :edit-bindings '((lexical-binding t))

>From now on, we'll do our observations evaluating the forms in source
code blocks via =C-c ' C-M-x=, and evaluating variables via =M-:= in
the edit special buffer.

In edit-special buffer, when editing, we observe that
~lexical-binding~ is set to ~t~:

#+BEGIN_SRC elisp
(eq lexical-binding t)
#+END_SRC

But ~truncate-lines~ is not set:

#+BEGIN_SRC elisp
(eq truncate-lines 62)
#+END_SRC

Copy ~truncate-lines~ over from this file's buffer local variables:

#+BEGIN_SRC elisp :edit-bindings '(truncate-lines)
(list lexical-binding truncate-lines)
#+END_SRC

We observe that now the buffer-wide value is shadoved, and while
truncate lines is passed through, ~lexical-binding~ is not, it's nil.

So we pass both through:

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t) truncate-lines)
(list (eq truncate-lines 62)
  (eq lexical-binding t))
#+END_SRC

Export blocks can not use header arguments.  Thus we use an element
property called ~ATTR_EDIT~:

#+ATTR_EDIT: ((fill-column 30) truncate-lines)
#+BEGIN_EXPORT latex
Nullam eu ante vel est
convallis dignissim.  Fusce
suscipit, wisi nec facilisis
facilisis, est dui fermentum
leo, quis tempor ligula erat
quis odio.  Nunc porta
vulputate tellus.  Nunc rutrum
turpis sed pede.  Sed
bibendum.
#+END_EXPORT

When we observe the value of ~truncate-lines~, we see that it is 62,
and when we use ~fill-paragraph~, that it wraps according to the new
value of ~fill-column~.

We get an error if we supply a bad varlist, but editing continues
anyways:

#+BEGIN_SRC python :edit-bindings '(("monty" "python"))
print(None)
#+END_SRC

#+ATTR_EDIT: Tea?
#+BEGIN_EXPORT latex
\textit{nope}
#+END_EXPORT

# Local Variables:
# truncate-lines: 62
# End:

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-02 12:16 +02, Nicolas Goaziou  wrote:
> Export blocks, like any other element, accept #+header: keyword, e.g.,
>
> #+header: whatever
> #+begin_export latex
>
> ...
> #+end_export
>
> Note that, however, such header arguments are ignored during export.

Thanks.  This means implementing this feature as a header argument
should suffice for all useful cases (though it'll probably become more
clearer when it's implemented and tested).

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Hello,

Göktuğ Kayaalp  writes:

> Also, another question remains: how do we extend this to #+begin_export
> blocks?  But that's unclear to me maybe because I don't know in detail
> how header arguments work.  Ideally this feature would work for _any
> block_ editable by ‘org-edit-special’ (i.e. C-c '), and again ideally
> using the same syntax.

Export blocks, like any other element, accept #+header: keyword, e.g.,

#+header: whatever
#+begin_export latex
...
#+end_export

Note that, however, such header arguments are ignored during export.

Regards,

-- 
Nicolas Goaziou

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-02 01:12 +03, Göktuğ Kayaalp  wrote:
> Okay, I'll read up on these, both code and manuals.  So we've agreed
> that what we want is a new header argument, ‘:edit-vars’, whose value is
> a form similar to a varlist, where
>
> - a form (var val) means bind var to val in the editing buffer,
>
> - a symbol var means bind var in the editing buffer to the buffer-local
>   value of it in the relevant x.org buffer, as in (setq
>   (make-local-variable var) (with-current-buffer "x.org" var))
>
> Do you confirm?  Also, what do you think about :edit-bindings or
> :edit-locals instead of :edit-vars? :var is a completely different
> thing, and :edit-vars may cause confusion, given the similarity of the
> name.

Also, another question remains: how do we extend this to #+begin_export
blocks?  But that's unclear to me maybe because I don't know in detail
how header arguments work.  Ideally this feature would work for _any
block_ editable by ‘org-edit-special’ (i.e. C-c '), and again ideally
using the same syntax.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen:

[...]

> So we've agreed
> that what we want is a new header argument, ‘:edit-vars’, whose value is
> a form similar to a varlist, where
> 
> - a form (var val) means bind var to val in the editing buffer,
> 
> - a symbol var means bind var in the editing buffer to the buffer-local
>   value of it in the relevant x.org buffer, as in (setq
>   (make-local-variable var) (with-current-buffer "x.org" var))
> 
> Do you confirm?  

Thatʼs how I understand the proposal, and it seems good to me.

> Also, what do you think about :edit-bindings or :edit-locals instead
> of :edit-vars? :var is a completely different thing, and :edit-vars
> may cause confusion, given the similarity of the name.

Agreed.  I prefer -bindings, but I suppose itʼs not terribly important:
either of your proposed names is a big improvement.

-- 
Aaron Ecay

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-01 21:53 +01, Aaron Ecay  wrote:
> That is excellent news :) If you run into anything you canʼt figure out
> then let us know.

I will probably be able to start working on this next weekend (tho there
is some stuff that can inevitably slow me down this week).  In the mean
time other people can comment both on this and on where to put the
resulting feature.

> But because of the nature of the variable (a lisp list), it can only be
> set once.  So you can have only one of:
> [...]
> But they canʼt be combined.  AFAIR, :var is the only header argument
> that can be meaningfully specified more than once.

Okay, I'll read up on these, both code and manuals.  So we've agreed
that what we want is a new header argument, ‘:edit-vars’, whose value is
a form similar to a varlist, where

- a form (var val) means bind var to val in the editing buffer,

- a symbol var means bind var in the editing buffer to the buffer-local
  value of it in the relevant x.org buffer, as in (setq
  (make-local-variable var) (with-current-buffer "x.org" var))

Do you confirm?  Also, what do you think about :edit-bindings or
:edit-locals instead of :edit-vars? :var is a completely different
thing, and :edit-vars may cause confusion, given the similarity of the
name.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen:
> 
> 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™ 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

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

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™ 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.

> 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:

-*- fill-column: 65; indent-tabs-mode: nil -*-
#+edit-vars: (indent-tabs-mode)
#+begin_src emacs-lisp :edit-vars (fill-column (lexical-binding t))
;; here, when editing, fill-column is 65, lexical binding is t
;; and indent-tabs-mode is nil
#+end_src

> PS Itʼs best to use “reply all” and include the org mode mailing list in
> replies, to make sure everyone following the thread sees all the
> messages.

Whoops! Sorry, yeah, I have been hitting the wrong keybinding for the
last couple of messages I think...

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen:

[...]

>> The approach that should be taken should be to use a header argument to
>> specify an alist of variables and values to set in src block edit buffers.
>> Then the usual methods (info "(org) Using header arguments") could be used
>> to control the feature globally, per-buffer, per-language, per-subtree,
>> and per-individual source block.
> 
> I agree.  But note that what I want to do is to set some buffer local
> variables in the special block editing buffer.  The header argument
> ":lexical yes" seems to not affect the editing buffer

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.

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.

Aaron

PS Itʼs best to use “reply all” and include the org mode mailing list in
replies, to make sure everyone following the thread sees all the
messages.

-- 
Aaron Ecay

Re: [O] Inheriting some local variables from source code block editing buffers

[Aaron Ecay]

2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen:
> 
> No, because you can use Noweb syntax wherever you need these local
> variables set:
> 
>   <>

This would still require adding something to each source block, which I
think Göktuğ wants to avoid doing.

With respect to the original proposal, I donʼt think itʼs a good idea to
inherit the values from the org buffer.  I can imagine that one might
want to have different values of (e.g.) fill-column in org-mode vs
emacs-lisp-mode.

The approach that should be taken should be to use a header argument to
specify an alist of variables and values to set in src block edit buffers.
Then the usual methods (info "(org) Using header arguments") could be used
to control the feature globally, per-buffer, per-language, per-subtree,
and per-individual source block.

If this isnʼt desired as a core feature I wouldnʼt see an impediment to
having it be part of org-contrib, though it could also be distributed
via (GNU/M)ELPA; it would be Göktuğʼs choice I guess.

Aaron

PS My view is the lexical-binding case is important enough that this
feature should be included in core, and that core should default to
lexical-binding: t in elisp src blocks

-- 
Aaron Ecay

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Göktuğ Kayaalp  writes:

> On 2018-05-01 13:55 +02, Nicolas Goaziou  wrote:
>
>> No, because you can use Noweb syntax wherever you need these local
>> variables set:
>>
>>   <>
>
> This seems to only expand when tangling,

When tangling, exporting and evaluating.

> not while editing via C-c '.

Correct.

> What I propose is about setting up the editing buffer (e.g. making
> sure in the org-edit-special lexical-binding is the same as in the
> org-mode buffer so that the results from live evaluation and from when
> tangling and loading the file agree).

Lexical binding is not a good example, because there's already a header
argument to control this:

  #+begin_src emacs-lisp :lexical t
  ...
  #+end_src

and you can set header arguments document-wise, or globally.

Other file local variables you could set in an Org buffer do not usually
make sense in programming languages.

I'm Cc'ing Emacs Org mailing list.

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Göktuğ Kayaalp  writes:

> But in my case (which is quite common I think) this would require adding
> those local variables sections to each code block.  My Emacs config
> alone has upwards of 170 code blocks, which means same three lines
> repeated 170 times adding up to extra 510 lines, just for setting one
> variable consistently.

No, because you can use Noweb syntax wherever you need these local
variables set:

  <>

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

BTW I can also implement this as a 3rd party extension instead of as a
core feature, I can see how it's possibly not generic enough for that.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-05-01 10:43 +02, Nicolas Goaziou  wrote:
> I think this machinery is not necessary.
>
> First add a call to `hack-local-variables-apply' somewhere in
> `org-src--edit-element'.
>
> Then, just use regular file-local variables ,e.g.,
>
> #+begin_src emacs-lisp
> (foo)
> ;; Local Variables:
> ;; fill-column: 99
> ;; End:
> #+end_src

But in my case (which is quite common I think) this would require adding
those local variables sections to each code block.  My Emacs config
alone has upwards of 170 code blocks, which means same three lines
repeated 170 times adding up to extra 510 lines, just for setting one
variable consistently.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> First add a call to `hack-local-variables-apply' somewhere in
> `org-src--edit-element'.

I meant `hack-local-variables'.

Re: [O] Inheriting some local variables from source code block editing buffers

[Nicolas Goaziou]

Hello,

Göktuğ Kayaalp  writes:

> One case I can think of is to set variables like fill-column when
> editing inline LaTeX, HTML,  blocks, and also, those like
> c-file-style, where say when writing a paper the author wants to use k
> style, but when writing a literate source prefers gnu style.
>
> Maybe a good way to achieve this would be to have the way you suggest to
> set defaults for Babel, but allow to define such bindings also in
> individual org mode files, either via the local variables or with a
> specific #+keyword like:
>
> #+edit_special_bindings: lexical-binding:t
> # or
> #+edit_special_bindings: c-file-style:gnu fill-column:80
>
> which is better IMO because there is no need to declare separately which
> variables to copy, and is more granular.  Also, in this case, a shortcut
> syntax for inheriting the buffer local value of a variable can be
> useful:
>
>  x.org ===
> # -*- fill-column: 65 -*-
> #+edit_special_bindings: c-file-style:gnu fill-column*
>
> This can be useful when one needs/wants to keep a consistent style in a
> given file.

I think this machinery is not necessary.

First add a call to `hack-local-variables-apply' somewhere in
`org-src--edit-element'.

Then, just use regular file-local variables ,e.g.,

#+begin_src emacs-lisp
(foo)
;; Local Variables:
;; fill-column: 99
;; End:
#+end_src

Regards,

-- 
Nicolas Goaziou

Re: [O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

On 2018-04-30 00:09 +02, Bastien  wrote:
> Hi Göktuğ,
>
> thanks for your patch.

You're welcome!

> Kayaalp  writes:
> Do you have other examples on local variables that would be useful to
> pass on when editing code in Org Src buffers?

Currently I only pass on lexical-binding and truncate-lines, and I do
not have another concrete example in my configuration (I do not use
source blocks for anything other than shell and elisp currently).  But I
have listed some hypothetical use cases further down.

> In general, instead of inheriting values from the Org's buffer, I'd
> allow users to set the values independantly -- for example, the cdr
> of elements in `org-babel-load-languages', instead of being `t' all
> the time (because nil makes no sense to me), could contain an alist
> of variables and their local values when editing and... executing.

This might be a better way indeed.  But this setting is then global,
i.e. one can't have the file A.org have lexical-binding on, but B.org
off (which might be necessary for say an older org file that depends on
lexical binding).

> This is: *if* we find cases that seem generic enough.
>
> What do you think?

One case I can think of is to set variables like fill-column when
editing inline LaTeX, HTML,  blocks, and also, those like
c-file-style, where say when writing a paper the author wants to use k
style, but when writing a literate source prefers gnu style.

Maybe a good way to achieve this would be to have the way you suggest to
set defaults for Babel, but allow to define such bindings also in
individual org mode files, either via the local variables or with a
specific #+keyword like:

#+edit_special_bindings: lexical-binding:t
# or
#+edit_special_bindings: c-file-style:gnu fill-column:80

which is better IMO because there is no need to declare separately which
variables to copy, and is more granular.  Also, in this case, a shortcut
syntax for inheriting the buffer local value of a variable can be
useful:

 x.org ===
# -*- fill-column: 65 -*-
#+edit_special_bindings: c-file-style:gnu fill-column*

This can be useful when one needs/wants to keep a consistent style in a
given file.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Inheriting some local variables from source code block editing buffers

[Bastien]

Hi Göktuğ,

thanks for your patch.

Kayaalp  writes:

> when editing a source block, passing some local variables from the
> original buffer into the buffer in which the source code is edited might
> be useful.  My use case is passing the value of ‘lexical-binding’ when
> editing Elisp source code blocks in my literate .emacs so that I don't
> mistakenly evaluate code in a non-lexical environment thinking it's the
> opposite instead.

Yes, I see how this can be useful in this case.

Do you have other examples on local variables that would be useful to
pass on when editing code in Org Src buffers?

> I've implemented this with the patch attached to this message, if it's
> deemed useful, I can revise it for inclusion upstream (just wanted to
> see what you think about the idea with this one).

Note that in the particular case of lexical-binding and emacs-lisp
blocks, there is the :lexical block parameter -- of course, this is
for execution, not edition, but you can use it as a clue on whether
the block supposes lexical binding or not.

In general, instead of inheriting values from the Org's buffer, I'd
allow users to set the values independantly -- for example, the cdr
of elements in `org-babel-load-languages', instead of being `t' all
the time (because nil makes no sense to me), could contain an alist
of variables and their local values when editing and... executing.

This is: *if* we find cases that seem generic enough.

What do you think?

-- 
 Bastien

[O] Inheriting some local variables from source code block editing buffers

[Göktuğ Kayaalp]

Hello,

when editing a source block, passing some local variables from the
original buffer into the buffer in which the source code is edited might
be useful.  My use case is passing the value of ‘lexical-binding’ when
editing Elisp source code blocks in my literate .emacs so that I don't
mistakenly evaluate code in a non-lexical environment thinking it's the
opposite instead.

I've implemented this with the patch attached to this message, if it's
deemed useful, I can revise it for inclusion upstream (just wanted to
see what you think about the idea with this one).

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 850525b8d..248b46462 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -196,6 +196,14 @@ For example, there is no ocaml-mode in Emacs, but the mode to use is
 	   (string "Language name")
 	   (symbol "Major mode"
 
+(defcustom org-src-inherited-local-variables '()
+  "Local variables to be copied into source code editing buffers.
+This variable contains a list of symbols, whose values in the Org
+mode buffer that contains the source block are to be interited by
+the source code editing buffer."
+  :group 'org-edit-structure
+  :type '(repeat symbol))
+
 (defcustom org-src-block-faces nil
   "Alist of faces to be used for source-block.
 Each element is a cell of the format
@@ -947,9 +955,13 @@ name of the sub-editing buffer."
 (unless (and (memq type '(example-block src-block))
 		 (org-src--on-datum-p element))
   (user-error "Not in a source or example block"))
-(let* ((lang
+(let* ((org-buffer (current-buffer))
+   (lang
 	(if (eq type 'src-block) (org-element-property :language element)
 	  "example"))
+   (buffer-name (or edit-buffer-name
+	(org-src--construct-edit-buffer-name
+ (buffer-name) lang)))
 	   (lang-f (and (eq type 'src-block) (org-src--get-lang-mode lang)))
 	   (babel-info (and (eq type 'src-block)
 			(org-babel-get-src-block-info 'light)))
@@ -957,10 +969,7 @@ name of the sub-editing buffer."
   (when (and (eq type 'src-block) (not (functionp lang-f)))
 	(error "No such language mode: %s" lang-f))
   (org-src--edit-element
-   element
-   (or edit-buffer-name
-	   (org-src--construct-edit-buffer-name (buffer-name) lang))
-   lang-f
+   element buffer-name lang-f
(and (null code)
 	(lambda () (org-escape-code-in-region (point-min) (point-max
(and code (org-unescape-code-in-string code)))
@@ -973,6 +982,9 @@ name of the sub-editing buffer."
 	(let ((edit-prep-func (intern (concat "org-babel-edit-prep:" lang
 	  (when (fboundp edit-prep-func)
 	(funcall edit-prep-func babel-info
+  (dolist (localvar org-src-inherited-local-variables)
+(set (make-local-variable localvar)
+ (with-current-buffer org-buffer (eval localvar
   t)))
 
 (defun org-edit-inline-src-code ()