From: "Göktuğ Kayaalp" <self@gkayaalp.com>
To: emacs-orgmode@gnu.org
Subject: Re: Inheriting some local variables from source code block editing buffers
Date: Mon, 14 May 2018 08:44:15 +0300 [thread overview]
Message-ID: <ygmefie3i6o.fsf@gkayaalp.com> (raw)
In-Reply-To: <ygmefiy3p88.fsf@gkayaalp.com> ("Göktuğ Kayaalp"'s message of "Sun, 29 Apr 2018 20:19:03 +0300")
[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]
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 &rest args)
attr-edit&edit-bindings)
"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 <https://www.gkayaalp.com/>
024C 30DD 597D 142B 49AC
40EB 465C D949 B101 2427
[-- Attachment #2: Testing instructions. --]
[-- Type: text/x-org, Size: 2374 bytes --]
# $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:
next prev parent reply other threads:[~2018-05-14 6:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 17:19 Inheriting some local variables from source code block editing buffers Göktuğ Kayaalp
2018-04-29 22:09 ` Bastien
2018-05-01 3:30 ` Göktuğ Kayaalp
2018-05-01 8:43 ` Nicolas Goaziou
2018-05-01 8:45 ` Nicolas Goaziou
2018-05-01 11:41 ` Göktuğ Kayaalp
2018-05-01 11:55 ` Nicolas Goaziou
[not found] ` <ygmvac7lcl1.fsf@gkayaalp.com>
2018-05-01 14:00 ` Nicolas Goaziou
2018-05-01 16:37 ` Aaron Ecay
[not found] ` <ygmin87kwua.fsf@gkayaalp.com>
2018-05-01 19:35 ` Aaron Ecay
2018-05-01 20:04 ` Göktuğ Kayaalp
2018-05-01 20:53 ` Aaron Ecay
2018-05-01 22:12 ` Göktuğ Kayaalp
2018-05-01 22:19 ` Aaron Ecay
2018-05-01 22:26 ` Göktuğ Kayaalp
2018-05-02 10:16 ` Nicolas Goaziou
2018-05-02 19:52 ` Göktuğ Kayaalp
2018-05-01 11:45 ` Göktuğ Kayaalp
2018-05-14 5:44 ` Göktuğ Kayaalp [this message]
2018-05-14 12:13 ` Nicolas Goaziou
2018-05-14 16:34 ` Göktuğ Kayaalp
2018-05-14 16:47 ` Nicolas Goaziou
2018-05-15 18:36 ` Göktuğ Kayaalp
2018-05-18 21:48 ` Göktuğ Kayaalp
2018-05-19 12:26 ` Nicolas Goaziou
2018-05-21 14:20 ` Aaron Ecay
2018-05-14 13:33 ` Aaron Ecay
2018-05-14 16:46 ` Göktuğ Kayaalp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ygmefie3i6o.fsf@gkayaalp.com \
--to=self@gkayaalp.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).