From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [PATCH 0/3] synctex support for pdf export Date: Mon, 01 Apr 2013 11:33:56 -0400 Message-ID: <876206uuxn.fsf@gmail.com> References: <1364786101-16603-1-git-send-email-aaronecay@gmail.com> <87r4iutxvf.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]:55435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMh3I-00022R-FR for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 11:53:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMh3H-0008Rl-03 for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 11:53:44 -0400 Received: from mail-qa0-f44.google.com ([209.85.216.44]:58201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMgkA-0001oQ-Aa for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 11:33:58 -0400 Received: by mail-qa0-f44.google.com with SMTP id o13so912133qaj.17 for ; Mon, 01 Apr 2013 08:33:58 -0700 (PDT) In-Reply-To: <87r4iutxvf.fsf@gmail.com> 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Hi Nicolas, 2013ko apirilak 1an, Nicolas Goaziou-ek idatzi zuen: >=20 > Async export works out of-the-box (though not optimized). There's no > special environment to set up. For me, when I tried it the async emacs process died because it could not find an external elisp library that I load from my init.el. I thought the problem was just a matter of me setting load-path incorrectly or something, and never looked into it, since having async export was not very important to me at the time (it just seemed like a cool feature to try). 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. >=20 > As you notice, there are many limitations and I agree some of them will > be tedious to overcome. It also breaks asynchronous export. >=20 > Moreover, modifying both parser and core export framework for an > optional feature within a single back-end family is not right, IMO. I agree that this is suboptimal, yes. >=20 > While I acknowledge the investment put into this patch, I won't accept > it in its current form. I might consider it if it only modifies > ox-latex.el, 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. My next idea is to use #+name properties on src blocks, tables, etc. to try to line up the two buffers (:ID: properties could also be used, if present). However, this would be a pain, and I doubt it would work well enough to justify itself. 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). Thanks, --=20 Aaron Ecay