From: Aaron Ecay <aaronecay@gmail.com>
To: "Nicolas Goaziou" <mail@nicolasgoaziou.fr>,
"Göktuğ Kayaalp" <self@gkayaalp.com>
Cc: Bastien <bzg@gnu.org>, emacs-orgmode@gnu.org
Subject: Re: Inheriting some local variables from source code block editing buffers
Date: Tue, 01 May 2018 17:37:25 +0100 [thread overview]
Message-ID: <87bmdzbad6.fsf@gmail.com> (raw)
In-Reply-To: <878t93ioa1.fsf@nicolasgoaziou.fr>
2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen:
>
> No, because you can use Noweb syntax wherever you need these local
> variables set:
>
> <<local-variables>>
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
next prev parent reply other threads:[~2018-05-01 16:37 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 [this message]
[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
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=87bmdzbad6.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=self@gkayaalp.com \
/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).