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