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ʼs probably possible to write an org-lint check for the most 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ʼs not impossible.) Iʼm still not 100% convinced that the breakage 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ʼt think anything should change for that case. -- Aaron Ecay
