From: "Clément Pit--Claudel" <clement.pit@gmail.com>
To: thibault.marin@gmx.com
Cc: emacs-orgmode@gnu.org
Subject: Re: Multiple bibliography files with ox-bibtex and html export
Date: Sat, 10 Sep 2016 12:31:27 -0400 [thread overview]
Message-ID: <49a92389-9eeb-84b9-fc5f-054aa6d7b2c2@gmail.com> (raw)
In-Reply-To: <87lgz0e18i.fsf@dell-desktop.WORKGROUP>
[-- Attachment #1.1: Type: text/plain, Size: 3826 bytes --]
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.
Cheers,
Clément.
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-09-10 16:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-24 4:14 Multiple bibliography files with ox-bibtex and html export Thibault Marin
2016-09-06 9:09 ` Nicolas Goaziou
2016-09-07 3:46 ` Thibault Marin
2016-09-07 4:11 ` Clément Pit--Claudel
2016-09-09 3:55 ` Thibault Marin
2016-09-10 6:07 ` Thibault Marin
2016-09-10 16:31 ` Clément Pit--Claudel [this message]
2016-09-28 3:50 ` Thibault Marin
2016-11-16 5:31 ` Thibault Marin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49a92389-9eeb-84b9-fc5f-054aa6d7b2c2@gmail.com \
--to=clement.pit@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=thibault.marin@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).