From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Fenton Subject: Re: latex exporting to different directory with v9.0 Date: Sun, 6 Nov 2016 12:39:37 +0100 Message-ID: References: <36258fcb-bc34-6517-2bc6-919722c3e72f@pressure.to> <874m3lo7v0.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3Lnb-00036n-TE for emacs-orgmode@gnu.org; Sun, 06 Nov 2016 06:39:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3LnY-0005pk-NF for emacs-orgmode@gnu.org; Sun, 06 Nov 2016 06:39:43 -0500 Received: from plato.servwise.com ([94.76.236.81]:53742) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c3LnY-0005oA-F7 for emacs-orgmode@gnu.org; Sun, 06 Nov 2016 06:39:40 -0500 Received: from x4e3472f2.dyn.telefonica.de ([78.52.114.242]:37242 helo=[192.168.178.25]) by plato.servwise.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c3LnW-000G2m-Ct for emacs-orgmode@gnu.org; Sun, 06 Nov 2016 11:39:38 +0000 In-Reply-To: <874m3lo7v0.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: emacs-orgmode@gnu.org Hello, On 05/11/16 23:54, Nicolas Goaziou wrote: > Honestly, I'm surprised it worked. I'm also surprised it could be > related to `default-directory' set-up, since links are created during > Org -> LaTeX conversion, whereas `org-compile-file' handles LaTeX -> > PDF. What is that "simple publishing set-up" you are talking about? Thanks for the reply. The publishing set up defines :publishing-directory as "out", and then the publishing function for each org file was: (defun thesis-publish-chapter-to-pdf (plist filename pub-dir) "Export a chapter to a LaTeX file in output dir and compile" (let ((outfile (org-publish-org-to 'latex filename "-chapter.tex" plist pub-dir))) (org-latex-compile (file-relative-name outfile)))) With org-latex-pdf-process being a standard "latexmk -xelatex -interaction=nonstopmode -f -outdir=%o -pdf %f" With 8.3, the latex process launches in the base (org) directory. Image & bibtex links in the tex file (in ./out) are resolved by latex relative to the base (working) directory. With 9.0, the enforced switch of default-directory to "./out" means the latex process is launched there instead, and relative links are no longer correctly resolved. > Basically, there are three directories to consider: source (".tex") > directory, output (".pdf") directory, and working directory, i.e., > probably ".org" file directory. > > The assumption for `org-compile-file', and before it, > `org-latex-compile', is that source and output directories are the same. That seems reasonable. All that I'd ideally like to continue to be able to do is keep a clean "working" (org) directory with correct relative links in the org files, and use a single other directory as "source" (tex) and "output" (pdf). > but others clearly require the working directory to be the output > directory (note the absence of output directory in the command below) > > "texi2dvi -p -b -V %f" I'm conscious that org-mode has to work with a lot of different backends and compilers, but that example should still work without switching default-directory; only the pdf file would end up not in ./out but ./. > As a consequence, if we do not set `default-directory' to the output > directory, the latter is broken. Note that if we do, "%o" place-holder > becomes useless as it is always "./". > > In a nutshell we can either set default-directory to source/output > directory or leave it as-is. In all cases, it seems to break something > anyway. I imagine the case for the vast majority of the time is that working, source and output directories are the same. I'm just wondering whether, for the cases where that's not true (calling a compiler from one directory to compile a file somewhere else), the responsibility for setting the correct default-directory, if necessary, could be left to the calling function, rather than having an enforced switch hard-coded in the core org-compile-file function. Thanks again, alex