From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vikas Rawal Subject: Re: "header-args :eval inline-only" not working Date: Sun, 20 Aug 2017 07:54:56 +0530 Message-ID: <7B90B949-C235-4F16-A2E5-4A22EB850DBC@agrarianresearch.org> References: <87fucnjr3h.fsf@nicolasgoaziou.fr> <672780F6-F156-4D48-8774-3E449FF4EA5B@agrarianresearch.org> <40F87DC3-9AF2-43D4-9E9D-11826219EA79@agrarianresearch.org> <06F7619D-A294-4AAE-89BA-DB9FC17FEDC2@ucsd.edu> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6A1D8FB-F6BE-43E8-88A0-4300EDB0C2D9" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djFvE-0003NC-Qc for emacs-orgmode@gnu.org; Sat, 19 Aug 2017 22:25:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djFvB-0000rr-LM for emacs-orgmode@gnu.org; Sat, 19 Aug 2017 22:25:04 -0400 Received: from mail-pg0-x242.google.com ([2607:f8b0:400e:c05::242]:35103) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djFvB-0000rU-AW for emacs-orgmode@gnu.org; Sat, 19 Aug 2017 22:25:01 -0400 Received: by mail-pg0-x242.google.com with SMTP id t80so13182945pgb.2 for ; Sat, 19 Aug 2017 19:25:01 -0700 (PDT) In-Reply-To: <06F7619D-A294-4AAE-89BA-DB9FC17FEDC2@ucsd.edu> 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: "Berry, Charles" Cc: org-mode mailing list , Nicolas Goaziou --Apple-Mail=_A6A1D8FB-F6BE-43E8-88A0-4300EDB0C2D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > There is a bug in the documentation -- `org-export-babel-evaluate' is = obsolete. It should say `org-export-use-babel=E2=80=99. I don=E2=80=99t see org-export-use-babel in available options. I cannot = customise it. '(org-export-use-babel (quote inline-only)) Seems to have no effect. Is that so because, as you say later, users are = not supposed to touch this option? > But that part of the manual is irrelevant to what the `:eval' header = does. There is no `inline-only' value in either the documentation or in = the lisp code. So, `inline-only' acts like `yes' for the reason I = stated earlier. >=20 >=20 >> With current org, I get this behaviour only if I globally set the = option. But that somehow disables ":results=E2=80=9D. >>=20 >=20 > Right. `:results' is a babel header. When babel is off, the babel = headers are not acted upon. >=20 > Setting `org-export-use-babel' to `nil' or `inline-only' turns off = babel for src blocks. >=20 >=20 > The behavior was purposely changed. With `inline-only' none of the = babel operations will be executed for src blocks -- i.e. the src blocks = and existing results (if any) will be exported as is. =20 >=20 > Users should avoid touching `org-export-use-babel' for almost all = purposes. It does not do the equivalent of setting `:eval' globally. >=20 I just saw this thread: = https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00443.html = I certainly feel that the current behaviour is a regression. The user = should have the possibility of controlling globally or buffer-wide = whether the source codes are evaluated at the time of export or not. = org-export-use-babel does not do that. It turns off babel completely, = exporting codes and existing results as is. This is clearly a regression as far as my use case is concerned. Vikas --Apple-Mail=_A6A1D8FB-F6BE-43E8-88A0-4300EDB0C2D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


There is a bug in the = documentation  -- `org-export-babel-evaluate' is obsolete. It = should say `org-export-use-babel=E2=80=99.
I don=E2=80=99t see org-export-use-babel in available = options. I cannot customise it.

'(org-export-use-babel (quote = inline-only))

Seems to have no effect. Is that so because, as you say = later, users are not supposed to touch this option?

But that part of the manual is irrelevant to = what the `:eval' header does.  There is no `inline-only' value in = either the documentation or in the lisp code.  So, `inline-only' = acts like `yes' for the reason I stated earlier.


With = current org, I get this behaviour only if I globally set the option. But = that somehow disables ":results=E2=80=9D.


Right. `:results' is a babel = header.  When babel is off, the babel headers are not acted = upon.

Setting `org-export-use-babel' to = `nil' or `inline-only' turns off babel for src blocks.


The behavior = was purposely changed. With `inline-only' none of the babel operations = will be executed for src blocks  -- i.e. the src blocks and = existing results (if any) will be exported as is.  
Users should avoid touching `org-export-use-babel' for = almost all purposes.  It does not do the equivalent of setting = `:eval' globally.




I certainly feel that = the current behaviour is a regression. The user should have the = possibility of controlling globally or buffer-wide whether the source = codes are evaluated at the time of export or not. org-export-use-babel = does not do that. It turns off babel completely, exporting codes and = existing results as is.

This is = clearly a regression as far as my use case is concerned.

Vikas



= --Apple-Mail=_A6A1D8FB-F6BE-43E8-88A0-4300EDB0C2D9--