From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH 0/3] synctex support for pdf export Date: Thu, 04 Apr 2013 15:19:35 +0200 Message-ID: <87mwtexwk8.fsf@gmail.com> References: <1364786101-16603-1-git-send-email-aaronecay@gmail.com> <87r4iutxvf.fsf@gmail.com> <876206uuxn.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNk4t-0001wM-Lr for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:19:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNk4r-0000VA-1A for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:19:43 -0400 Received: from mail-we0-x235.google.com ([2a00:1450:400c:c03::235]:64750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNk4q-0000V3-Qs for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:19:40 -0400 Received: by mail-we0-f181.google.com with SMTP id d7so2023768wer.12 for ; Thu, 04 Apr 2013 06:19:40 -0700 (PDT) In-Reply-To: <876206uuxn.fsf@gmail.com> (Aaron Ecay's message of "Mon, 01 Apr 2013 11:33:56 -0400") 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hello, Aaron Ecay writes: > Now that this has come up, I have looked at it more. It appears that > the /usr/share/emacs/site-lisp directory is not added to load-path in > the async export process. I guess that it should be, since users=E2=80=99 > init.el files could rely on libraries that are found there. This is debatable. I think that the sub-process shouldn't load too much libraries. In your case, you effectively need to tweak `org-export-async-init-file'. > This will make the problem very difficult, if not impossible. Generally > speaking, the buffer that the export functions see bears only a loose > relationship to the original buffer, since babel blocks, #+include > directives, etc. have changed the text. I have tried to think of ways > to get around this fact, since working with the synctex file requires > knowing the original line number. This is the best I could do. [...] > Do you have any ideas about how this might be overcome? What is needed > is to know, for any line in the exported output, which line of the org > file it corresponds to (within some small margin of error). I don't think there is a complete solution to this problem. Though `org-export-before-processing-hook' allows to work on an exact copy of the buffer being exported before any file is included and any Babel block executed. You can add text properties there. And with `org-export-before-parsing-hook', you can check what parts of the buffer are new (generated from include keywords, macros and blocks). From there it may be possible to implement a lookup function which would find the appropriate line in the original buffer. Regards, --=20 Nicolas Goaziou