From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= Subject: Re: Multiple bibliography files with ox-bibtex and html export Date: Sat, 10 Sep 2016 12:31:27 -0400 Message-ID: <49a92389-9eeb-84b9-fc5f-054aa6d7b2c2@gmail.com> References: <87k2f6x0q6.fsf@dell-desktop.WORKGROUP> <87vay9v1h1.fsf@saiph.selenimh> <871t0wl6by.fsf@dell-desktop.WORKGROUP> <61fbf71f-3809-7460-5ead-265c8c9e6f66@gmail.com> <87lgz0e18i.fsf@dell-desktop.WORKGROUP> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mWQ3vVCH9OBNGjt60EpKVj2VNKrs3m8eI" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bilBu-0002lS-5n for emacs-orgmode@gnu.org; Sat, 10 Sep 2016 12:31:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bilBq-0007d0-3w for emacs-orgmode@gnu.org; Sat, 10 Sep 2016 12:31:42 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:62673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bilBp-0007cV-Pb for emacs-orgmode@gnu.org; Sat, 10 Sep 2016 12:31:38 -0400 In-Reply-To: <87lgz0e18i.fsf@dell-desktop.WORKGROUP> 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" To: thibault.marin@gmx.com Cc: emacs-orgmode@gnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mWQ3vVCH9OBNGjt60EpKVj2VNKrs3m8eI Content-Type: multipart/mixed; boundary="LCGpufxpfwSrxxn2d5FmeDqJATaxgNNGv"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: thibault.marin@gmx.com Cc: emacs-orgmode@gnu.org Message-ID: <49a92389-9eeb-84b9-fc5f-054aa6d7b2c2@gmail.com> Subject: Re: [O] Multiple bibliography files with ox-bibtex and html export References: <87k2f6x0q6.fsf@dell-desktop.WORKGROUP> <87vay9v1h1.fsf@saiph.selenimh> <871t0wl6by.fsf@dell-desktop.WORKGROUP> <61fbf71f-3809-7460-5ead-265c8c9e6f66@gmail.com> <87lgz0e18i.fsf@dell-desktop.WORKGROUP> In-Reply-To: <87lgz0e18i.fsf@dell-desktop.WORKGROUP> --LCGpufxpfwSrxxn2d5FmeDqJATaxgNNGv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd suggest 2 :) But not that I don't use this feature. It should be easy to unify the code: something along the lines of startin= g the process, and then looping over bibtex files and sending them one by= one to bibtex2html's standard input. Cheers, Cl=C3=A9ment. On 2016-09-10 02:07, Thibault Marin wrote: >=20 >=20 > Do you mean: > 1) Using `call-process' for cases where a single bibliography file is > passed and `process-send-string' when multiple files are used? > 2) Using `process-send-string' regardless of the number of bibliography= > files? In this case, can we still unify the code between single and > multiple files? > 3) Something else? >=20 > In my opinion 1) makes the code more error-prone and harder to > maintain. If there are other reasons to replace the existing behavior > (for single bibliography files) by `process-send-string', then 2) may > make sense, otherwise it sounds to me that it may not be worth it: the > existing code is apparently working fine for single files, I would feel= > a little uncomfortable changing it based only on my test case, > especially since there isn't (as far as I know) a battery of tests for > it. >=20 > - Is having a temporary file unacceptable? >=20 > The first patch creates and keeps the combined bibliography around, but= > this created file could easily be deleted if preferred. If the problem= > is just the extra file, the first patch can fix it and seems less > intrusive to me. >=20 > - Is the main concern performance? >=20 > I think that the main argument for using standard input may be to skip > the disk access required by the temporary file. I do not know if the > potential savings for files of size around a few MB (or more?) justify > the more intrusive change in the code. Maybe others would have a bette= r > feel for this than I do. >=20 > Thanks for the comments on this. Once a consensus is reached, I can > work towards an updated patch. >=20 > thibault >=20 >> I'd suggest starting the process and then using process-send-string. >> >> Cl=C3=A9ment. >> >> On 2016-09-08 23:55, Thibault Marin wrote: >>> >>> Cl=C3=A9ment Pit--Claudel writes: >>> >>>> On 2016-09-06 23:46, Thibault Marin wrote: >>>>>>> I am attaching a patch which allows me to use multiple files with= html >>>>>>> export. It creates a combined bibliography file and call bibtex2= html on >>>>>>> it. I am not sure this is the best way to address this, so any >>>>>>> suggestion would be welcome. >>>> >>>> Sorry for the late comment. bibtex2html can read from standard inpu= t; maybe that would be cleaner? >>>> >>>> Cl=C3=A9ment. >>> >>> That may be a good idea, it would prevent potential name clashing wit= h >>> the created bib file. Currently, the function creates a >>> -combined.bib file with the content of all >>> bibliography files, then bibtex2html creates >>> -combined.html and >>> -combined_bib.html. Passing the contents via stdin= >>> would skip the -combined.bib. We could achieve the= >>> same by simply deleting -combined.bib after calling= >>> bibtex2html. I personally don't mind leaving the .bib file after >>> processing, but if there is a consensus to limit the side effect, we = can >>> do that. >>> >>> As far as the implementation goes, I am not sure what is the best way= to >>> get this to work with stdin. In the attached patch (which does *not*= >>> work) I tried to use `call-process-region' and dump the bibliography >>> files into a temporary buffer. This complicates the code a little. >>> Alternatively, we could use the `INFILE' parameter from `call-process= ', >>> but it looks that this would require a file, so it would not change m= uch >>> from the previous patch. >>> >>> Any thoughts? >>> >=20 --LCGpufxpfwSrxxn2d5FmeDqJATaxgNNGv-- --mWQ3vVCH9OBNGjt60EpKVj2VNKrs3m8eI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX1DVfAAoJEPqg+cTm90wj3iUP/2dhEMkfAhGVe6clwsaUIC+1 hHf+HCcN50UJWOfHDbiqCAEZJvJf5fKX3m9hiP0yxToDq9wDSi6+711GPLX3wJNL q93EkMpMYvHIQ2I8X4QpeX18Uw2UJFrx/NUDN8kd01d8xX+NBIRJHWE5i1SogZu0 yTH3dQ7QZo3YbewI16LyRD8FJbpdJ+2Nh1Ppu+/K8Rve5eoWmbq6TQZpeyrfkMgv XZhSbyKqTHgJZ9ldOYDjEzCDTloykYmOfNYYWS7+hzKVO/h8J5+7KUrE6Jurz0g9 U0bxOHOc0/amdMwaT/vNIXLmXUpkOSmoqwwjoyHouG+N8OJdS4+2eb6L9BWaX1Zo fkOFsErmT54m3krjH2IMFJiYlG/erAZ3GbkPby/plIxmU0YeSr6G9NH8o/Pc23h+ 4Of7Hy2PN3dtyxJAcVUNTizi9JOX4VkIMf+QF2Q7Kb689HQ9zESh6Pfh0tMmAvMI MD0Qy/ivC0pC+vHe4qERGXHJ8CU9IuMHagfm2uQX6IyzIUjm88pzkdIx2z6QaIO1 l8tiDAb6Lz58ugf1lZflUN+wquMWtoj6ZtqbFkGDiNIAQDCOJ5ArwXoMkTiLCKFn yXgJoueSCNEPovOwJF5Hb64eB+BJUwpaVJwrdjc82McQ5sUM1LxH3ie9FRcnFCnK cXFfZDAx9uAYyGp1OLFr =antM -----END PGP SIGNATURE----- --mWQ3vVCH9OBNGjt60EpKVj2VNKrs3m8eI--