From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thibault Marin Subject: Re: Multiple bibliography files with ox-bibtex and html export Date: Sat, 10 Sep 2016 01:07:57 -0500 Message-ID: <87lgz0e18i.fsf@dell-desktop.WORKGROUP> References: <87k2f6x0q6.fsf@dell-desktop.WORKGROUP> <87vay9v1h1.fsf@saiph.selenimh> <871t0wl6by.fsf@dell-desktop.WORKGROUP> <61fbf71f-3809-7460-5ead-265c8c9e6f66@gmail.com> Reply-To: thibault.marin@gmx.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bibST-0006A6-43 for emacs-orgmode@gnu.org; Sat, 10 Sep 2016 02:08:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bibSN-0006hf-Mv for emacs-orgmode@gnu.org; Sat, 10 Sep 2016 02:08:08 -0400 Received: from mout.gmx.net ([212.227.15.15]:65327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bibSN-0006hP-D5 for emacs-orgmode@gnu.org; Sat, 10 Sep 2016 02:08:03 -0400 In-reply-to: <61fbf71f-3809-7460-5ead-265c8c9e6f66@gmail.com> 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: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel Cc: emacs-orgmode@gnu.org 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? 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. - Is having a temporary file unacceptable? 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. - Is the main concern performance? 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 better feel for this than I do. Thanks for the comments on this. Once a consensus is reached, I can work towards an updated patch. thibault > I'd suggest starting the process and then using process-send-string. >=20 > Cl=C3=A9ment. >=20 > On 2016-09-08 23:55, Thibault Marin wrote: > >=20 > > Cl=C3=A9ment Pit--Claudel writes: > >=20 > >> 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > Any thoughts? > >=20