emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH 0/3] synctex support for pdf export


From: Aaron Ecay
Subject: Re: [O] [PATCH 0/3] synctex support for pdf export
Date: Mon, 01 Apr 2013 11:33:56 -0400
User-agent: Notmuch/0.15.2+43~ge848af8 (http://notmuchmail.org) Emacs/24.3.50.1 (x86_64-unknown-linux-gnu)

Hi Nicolas,

2013ko apirilak 1an, Nicolas Goaziou-ek idatzi zuen:
> 
> 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’
init.el files could rely on libraries that are found there.

> 
> As you notice, there are many limitations and I agree some of them will
> be tedious to overcome. It also breaks asynchronous export.
> 
> 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.

> 
> 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,

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]