From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Inheriting some local variables from source code block editing buffers Date: Tue, 01 May 2018 17:37:25 +0100 Message-ID: <87bmdzbad6.fsf@gmail.com> References: <874ljt3bs0.fsf@gnu.org> <87h8nrkbpw.fsf@nicolasgoaziou.fr> <878t93ioa1.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDYHW-0002Nl-BM for emacs-orgmode@gnu.org; Tue, 01 May 2018 12:37:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDYHV-0005II-Fy for emacs-orgmode@gnu.org; Tue, 01 May 2018 12:37:34 -0400 In-Reply-To: <878t93ioa1.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou , =?utf-8?B?R8O2a3R1xJ8=?= Kayaalp Cc: Bastien , emacs-orgmode@gnu.org 2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen: >=20 > No, because you can use Noweb syntax wherever you need these local > variables set: >=20 > <> This would still require adding something to each source block, which I think G=C3=B6ktu=C4=9F wants to avoid doing. With respect to the original proposal, I don=CA=BCt think it=CA=BCs 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=CA=BCt desired as a core feature I wouldn=CA=BCt see an impedim= ent to having it be part of org-contrib, though it could also be distributed via (GNU/M)ELPA; it would be G=C3=B6ktu=C4=9F=CA=BCs 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 --=20 Aaron Ecay