Aaron Ecay <aarone...@gmail.com> writes: > Hi Richard, hi all, > > 2015ko urriak 26an, Richard Lawrence-ek idatzi zuen: >> > > [...] > >>> I was working on this rather intensively at one time, but I had to stop >>> because other aspects of life intruded. I have just been coming back >>> towards a situation where I can imagine myself having some (still small, >>> but non-zero) chunks of time to devote to working on org. So I hope I >>> will be able to pick this back up, but (regrettably) I’m not able to >>> make any promises. >>> >>> Based on my recollection, here’s what the problems were when I stopped: >>> >>> - The only “off the shelf”-capable citation processing library that we >>> found last time is in Haskell, which introduced some difficulties for >>> distributing the resulting tool. I know some projects >>> (e.g. git-annex) are written in Haskell and distributed as static >>> binaries for windows/mac/linux/etc. We’d need to figure out how to do >>> this, or find another citation processing library in an >>> easier-to-distribute language. >> >> Yes, this is my understanding, too. In particular, there does not seem >> to be an Elisp CSL library, and it would be a lot of work to write one. >> >> The other CSL library that looks complete and usable is citeproc-js; but >> like the Haskell library (pandoc-citeproc) it would need to be wrapped >> somehow so that it can talk with Org. >> >> It should be relatively straightforward for someone who knows Javascript >> to write such a wrapper, if anyone wants to work on that. But this does >> not really solve the problem with distribution. > > It solves many of the hard problems though. Node.js is distributed > as a binary for many platforms. We’d just have to direct users to > install this in the “normal way,” and use the installed binary to > interpret the JS source. Whereas for haskell we’d be stuck building > the binary ourselves, worrying about static linking/dll hell/32-bit > dinosaurs/any of a half-dozen other problems that I don’t really > understand.
I would feel more comfortable relying on a JS library. Perhaps it’s also easier to find people who are willing to work on/knows JS over the long haul... > OTOH, pandoc-citeproc includes a bibtex parser; we’d need to write a JS > one and wire it up to citeproc-js. When I looked (quite some time ago), > there did not seem to be any good bibtex parsing libraries in JS (and > several third-rate ones). Bibtex support is essential, of course. Can someone remind me why citeproc-java isn’t good? AFAIR, it has a bibtex parser. But probably it lacks in some other dimension... > OT3rdH, responding to Matt’s message > <http://mid.gmane.org/can_dec_52sp6ghr56pudhih69ksprq0vdw2zmnp5799-cta...@mail.gmail.com>, > >> The disadvantage is that, from what I can tell, the javascript >> implementation is the canonical version of citeproc, and the place where >> improvements are pushed first. So, for instance, if one wanted to >> implement an org-syntax output format for citeproc, citeproc-js would be >> the most likely project to support that work. > > Pandoc can output org syntax, so it may be that we can just link with > the main pandoc haskell library as well as pandoc-citeproc and solve > this ourselves, without needing upstream support. Do we WANT to depend on Pandoc? I would say "no". In my OS, where we finally got a binary distribution of pandoc, the size of pandoc is still 1600Mb! I don’t know if this is representative of other systems, though. E.g. what is the size of pandoc+deps in Debian? Rasmus -- Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio