From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Price Subject: Re: Some projects Date: Wed, 28 Oct 2015 10:36:37 -0400 Message-ID: References: <87wpub9jts.fsf@nicolasgoaziou.fr> <877fmazh2f.fsf@gmail.com> <87fv0x1t49.fsf@berkeley.edu> <874mhczfil.fsf@gmail.com> <87k2q8mqwj.fsf@gmx.us> <871tcgzcoc.fsf@gmail.com> <87bnbkmnc2.fsf@gmx.us> <87bnbjr7mz.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113f9ae035a02105232b1f5c Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrRqG-0003xl-SU for emacs-orgmode@gnu.org; Wed, 28 Oct 2015 10:36:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrRqA-0003mM-Dn for emacs-orgmode@gnu.org; Wed, 28 Oct 2015 10:36:44 -0400 Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]:32981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrRqA-0003mA-95 for emacs-orgmode@gnu.org; Wed, 28 Oct 2015 10:36:38 -0400 Received: by iodd200 with SMTP id d200so12369767iod.0 for ; Wed, 28 Oct 2015 07:36:37 -0700 (PDT) In-Reply-To: <87bnbjr7mz.fsf@fastmail.fm> 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 Cc: Org Mode --001a113f9ae035a02105232b1f5c Content-Type: text/plain; charset=UTF-8 On Tue, Oct 27, 2015 at 11:31 PM, Matt Lundin wrote: > Matt Price writes: > > > On Tue, Oct 27, 2015 at 9:51 AM, Rasmus wrote: > > > > > > Aaron Ecay writes: > > > > Indeed. I guess this is what they use: > > > > https://github.com/zotero/citeproc-node > > > > It also looks rather complex... > > > > > > FWIW, I just tried installing this on my Arch system, but it doesn't > > work with node 0.12, and I am currently unable to switch to io.js due > > to dependencies of several other projects. I guess tools like NVM can > > help with this situation, but I worry that node is currently a moving > > target and might lead to lots of platform-dependent buggy behaviour. > > Testing it now... Works fine on my Arch system. Arch's current nodejs is > 4.2. As I understand it, io.js has been merged back into node 4.+ > upgraded from 0.12, and it works fine. My problem before was that some important npm packages were still incompatible with node 4.2; it may be that that's no longer an issue, and I spoke too soon. > > The citeproc-node server itself is not very complex. It's just a node > wrapper around citeproc-js. The big limitation, it seems to me, is that > it only accepts a json format as input. Also it seems to use html markup > in all its output formats. > That does seem to be an issue, but I bet it wouldn't be too hard to fix. Currently outputformat is hardcoded on line 94 of lib/citeServer.js; I'm a little slow at reading JS but I think replacing line 259 with a switch statement analogous to the one for responseformat at line 291 would allow one to use the full capacities of citeproc.js. I think the best route would probably be to submit a patch to citeproc.js adding an org-mode output format, propagating that up to citeproc-node, submitting a second patch to citeproc-node, and then writing the org-internal functions properly. We might also want to add an additional responseformat option. It might take a month or two to get all those changes accepted, but we could probably do the org-mode development simultaneously, and it would be worth the wait to have a stable solution. My experience with the citeproc-js maintainer is that he is very helpful and responsive to feature requests. I am a slow coder but would be happy to invest some time in this if it's the direction the community wants to go in. Adding a new output format to citeproc-js is not that complex; see https://bitbucket.org/fbennett/citeproc-js/src/tip/src/formats.js?fileviewer=file-view-default > Though published by the Zotero programmers, citeproc-node, I believe, is > distinct from the citeproc-js implementation in Zotero, which is a XUL > application. > > I think that's right. If we could avoid dependencies on Zotero that would be good; it is a pretty substantial program, takes up a significant amount of RAM at runtime, and relies on a GUI environment, which neither emacs nor pandoc does. > Matt > --001a113f9ae035a02105232b1f5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 27, 2015 at 11:31 PM, Matt Lundin <mdl@imapmail.org>= wrote:
Matt Price <moptop99@gma= il.com> writes:

> On Tue, Oct 27, 2015 at 9:51 AM, Rasmus <rasmus@gmx.us> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0Aaron Ecay <aaronecay@gmail.com> writes:
>
>=C2=A0 =C2=A0 =C2=A0Indeed. I guess this is wha= t they use:
>
>=C2=A0 =C2=A0 =C2=A0https://github.com/zotero/citeproc-no= de
>
>=C2=A0 =C2=A0 =C2=A0It also looks rather complex...
>
>
> FWIW, I just tried installing this on my Arch system, but it doesn'= ;t
> work with node 0.12, and I am currently unable to switch to io.js due<= br> > to dependencies of several other projects. I guess tools like NVM can<= br> > help with this situation, but I worry that node is currently a moving<= br> > target and might lead to lots of platform-dependent buggy behaviour.
Testing it now... Works fine on my Arch system. Arch's current n= odejs is
4.2. As I understand it, io.js has been merged back into node 4.+

upgraded from 0.12, and it works fine.=C2=A0 My = problem before was that some important npm packages were still incompatible= with node 4.2; it may be that that's no longer an issue, and I spoke t= oo soon.=C2=A0
=C2=A0

The citeproc-node server itself is not very complex. It's just a node wrapper around citeproc-js. The big limitation, it seems to me, is that
it only accepts a json format as input. Also it seems to use html markup in all its output formats.

That does se= em to be an issue, but I bet it wouldn't be too hard to fix.=C2=A0 Curr= ently outputformat is hardcoded on line 94 of lib/citeServer.js; I'm a = little slow at reading JS but I think replacing line 259 with a switch stat= ement analogous to the one for responseformat at line 291 would allow one t= o use the full capacities of citeproc.js.=C2=A0 I think the best route woul= d probably be to submit a patch to citeproc.js adding an org-mode output fo= rmat, propagating that up to citeproc-node, submitting a second patch to ci= teproc-node, and then writing the org-internal functions properly.=C2=A0 We= might also want to add an additional responseformat option.=C2=A0

=
It might take a month or two to get all those changes accepted, = but we could probably do the org-mode development simultaneously, and it wo= uld be worth the wait to have a stable solution.=C2=A0 My experience with t= he citeproc-js maintainer is that he is very helpful and responsive to feat= ure requests.=C2=A0

I am a slow coder but would be happy= to invest some time in this if it's the direction the community wants = to go in.=C2=A0 Adding a new output format to citeproc-js is not that compl= ex; see https://bitbucket.org/fbennett/ci= teproc-js/src/tip/src/formats.js?fileviewer=3Dfile-view-default

=

Though published by the Zotero programmers, citeproc-node, I believe, is distinct from the citeproc-js implementation in Zotero, which is a XUL
application.

I think that's right.=C2=A0 If we could avoid dependencies on Zotero = that would be good; it is a pretty substantial program, takes up a signific= ant amount of RAM at runtime, and relies on a GUI environment, which neithe= r emacs nor pandoc does. =C2=A0
=C2=A0
Matt

--001a113f9ae035a02105232b1f5c--