emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Göktuğ Kayaalp
Subject: Re: [O] Inheriting some local variables from source code block editing buffers
Date: Mon, 14 May 2018 19:46:47 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On 2018-05-14 14:33 +01, Aaron Ecay <address@hidden> 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       <https://www.gkayaalp.com/>
                         024C 30DD 597D 142B 49AC
                         40EB 465C D949 B101 2427



reply via email to

[Prev in Thread] Current Thread [Next in Thread]