On 4/24/11 4:21 PM, Eric Schulte wrote:
Matt Lundin<m...@imapmail.org> writes:
(...)
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.
Alright, I think I agree that separate packaging would be the best way
forward given the existing conventions wrt linking to functionality
rather than implementing said functionality.
The *conclusion* (where Eric Schulte's new bibtex functions should go)
is not a big concern to me, but FWIW, the *premise* strikes me as
unnecessarily restrictive.
I submit that, for any non-Org format or application "foo", the module
org-foo.el does not have to be restricted to providing an Org link
type for foo. It seems a sensible namespace for e.g. foo-Org/Org-foo
conversion functions as well. The fact that several modules so named
*at present* only provide link functionality does not, I think, amount
to a convention that this is all they should do.
> 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.
That's a great aim. Still, a future bibliography module (be it
"org-bib", "org-cite" or whatever) could just as well rely, for bits
of bibtex functionality, on some utilities packaged in org-bibtex.
Yours,
Christian
