[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Multiple bibliography files with ox-bibtex and html export

From: Clément Pit--Claudel
Subject: Re: [O] Multiple bibliography files with ox-bibtex and html export
Date: Sat, 10 Sep 2016 12:31:27 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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 starting the 
process, and then looping over bibtex files and sending them one by one to 
bibtex2html's standard input.


On 2016-09-10 02:07, Thibault Marin wrote:
> 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.
>> Clément.
>> On 2016-09-08 23:55, Thibault Marin wrote:
>>> Clément 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 bibtex2html 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 input; 
>>>> maybe that would be cleaner?
>>>> Clément.
>>> That may be a good idea, it would prevent potential name clashing with
>>> the created bib file.  Currently, the function creates a
>>> <name-of-org-file>-combined.bib file with the content of all
>>> bibliography files, then bibtex2html creates
>>> <name-of-org-file>-combined.html and
>>> <name-of-org-file>-combined_bib.html.  Passing the contents via stdin
>>> would skip the <name-of-org-file>-combined.bib.  We could achieve the
>>> same by simply deleting <name-of-org-file>-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 much
>>> from the previous patch.
>>> Any thoughts?

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]