From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Babel - :export-dir and :file-ext arguments cause all blocks to emit files Date: Fri, 25 May 2018 14:47:59 +0100 Message-ID: <87fu2f7sog.fsf@gmail.com> References: <3ac2f42a-8ff2-1464-fa36-451e2ef0eacd@pressure.to> <87wovsprzd.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]:36257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fMD4g-0004US-Sn for emacs-orgmode@gnu.org; Fri, 25 May 2018 09:48:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fMD4d-0001JF-QS for emacs-orgmode@gnu.org; Fri, 25 May 2018 09:48:06 -0400 Received: from mail-wr0-x22d.google.com ([2a00:1450:400c:c0c::22d]:45068) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fMD4d-0001Ii-JH for emacs-orgmode@gnu.org; Fri, 25 May 2018 09:48:03 -0400 Received: by mail-wr0-x22d.google.com with SMTP id w3-v6so9350840wrl.12 for ; Fri, 25 May 2018 06:48:03 -0700 (PDT) In-Reply-To: <87wovsprzd.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 , Alex Fenton Cc: emacs-orgmode@gnu.org Hi Nicolas, hi Alex, First of all, no issue arises with :output-dir alone. It can be specified as a global header arg without issue. The situation with :file is that it (currently and at all relevant times in the past AFAIK) implies :results file. That is because it would be a little strange if: #+begin_src R :file foo.pdf ... #+end_src did not result in the output going to foo.pdf I designed :file-ext as a direct replacement for :file. That is, instead of the above, one would specify: #+name: foo #+begin_src R :file-ext pdf ... #+end_src and get the same result. IOW, the design was *not* for :file-ext to be specified globally. This perhaps could have been documented better when it was first introduced, and I see that subsequent changes in the manual have not made things clearer. The change Nicolas proposes is how I would make :file-ext work if I were writing it from scratch today, with the benefit of hindsight. I worry that introducing it would break org documents in the wild, but maybe it is worth it. It=CA=BCs probably possible to write an org-lint check for the m= ost common broken case (where :file-ext is specified directly on a block, but :results file is not. This check would not catch a case where :file-ext was specified via a property for a buffer/subtree of blocks all of which are supposed to produce file results. Such a case should be rare, but it=CA=BCs not impossible.) I=CA=BCm still not 100% convinced that the brea= kage would be worth it, but I suppose I would incline towards that view. OTOH I do not think the proposed change makes sense for :file, because it would lead to a nonsensical situation in the case of the first block in this email. It never has made sense to specify :file by inheritance, so I don=CA=BCt think anything should change for that case. --=20 Aaron Ecay