emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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 --]

  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).