"Alan E. Davis" <lngn...@gmail.com> writes:

> This works to both store bibtex database entries and export to .bib
> files.  I REALLY like the automagical harvesting of data using cb2Bib. 
> It is unique, and I don't see how to recruit it to produce a database
> in an org file, or pipe it into this org-bibtex tool.  

Could one perhaps call org-bibtex-read on entries in harvested via

> I understand I may add to the types variable.  When using
> org-bibtex-create, I can enter any arbitrary field as a PROPERTY;
> however, org-bibtex ignores anything outside of the universe it knows
> about.  Would it be bad practice to allow the export of any arbitrary
> field type one has recorded?  I think the emacs bibtex-mode may
> recognize erroneous bibtex entries.   

Bibtex-mode does indeed allow for arbitrary fields, as do bibtex and
biblatex. AFAIK, they are simply ignored when processing a bib file. One
limitation that arises when storing bibtex data as org properties is
that properties drawers are used for much more. For instance, one would
probably not want to see "logging = {lognoterepeat}," in one's exported
bibtex file.

But for biblatex users, it would indeed be prohibitively expensive to
have to inform org-mode ahead of time about the innumerable odd fields
that various biblatex backends define.

> I am confused by the duplication of file names, though I can see that
> at some point one of the two will lose.  (Gauss's law of competitive
> exclusion, referring to the biological case of two species occupying
> the same ecological niche). 

Eric, the more I think about this, the more my vote would be to package
this new functionality separately.

IMO, hyperlinking to external data in bib files is somewhat orthogonal
to storing bib data within org files. In other words, the current
org-bibtex.el complements bibtex-mode use, whereas the new org-bibtex
functions, for the most part, are substitutes for bibtex-mode---i.e.,
they re-implement much of its configuration and basic functionality.

By packaging the new functionality separately perhaps we could lay the
groundwork for internal, backend agnostic bibliographical export and
formatting---not unlike the way in which org-contacts.el replaces bbdb.

Wishful thinking?... :)


Reply via email to