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

2018-05-21 Thread 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

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

2018-05-19 Thread 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

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

2018-05-18 Thread 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:

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

2018-05-15 Thread 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

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

2018-05-14 Thread 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

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

2018-05-14 Thread 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

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

2018-05-14 Thread 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

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

2018-05-14 Thread 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: [...]

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

2018-05-14 Thread 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

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

2018-05-14 Thread 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

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

2018-05-02 Thread 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

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

2018-05-02 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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

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

2018-05-01 Thread 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 >

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

2018-05-01 Thread 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

2018-05-01 Thread 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

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

2018-04-30 Thread 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

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

2018-04-29 Thread 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 >