[O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi, In an attempt to organize my reading notes, I've written the following tool which allows both for exporting Org-mode headlines with bibtex meta-data to bibtex entries, and for reading existing bibtex entries into Org-mode headings. One nice feature of these functions is the ability to check that all required fields are present in a given headline based on the bibtex type (e.g., :article, :inproceedings), and prompt for missing fields. See the top of the elisp file for more usage information. https://github.com/eschulte/org-bibtex/blob/master/org-bibtex.el Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
This looks great! I haven't quite read all the code, but I wonder how this would work on files where bib entries are in their own headline or mixed into the document ad hoc. Is this designed for a document with *only* bibtex headlines? On Tue, Apr 19, 2011 at 7:52 PM, Eric Schulte wrote: > Hi, > > In an attempt to organize my reading notes, I've written the following > tool which allows both for exporting Org-mode headlines with bibtex > meta-data to bibtex entries, and for reading existing bibtex entries > into Org-mode headings. > > One nice feature of these functions is the ability to check that all > required fields are present in a given headline based on the bibtex type > (e.g., :article, :inproceedings), and prompt for missing fields. > > See the top of the elisp file for more usage information. > https://github.com/eschulte/org-bibtex/blob/master/org-bibtex.el > > Cheers -- Eric > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/ > > -- Jeffrey Horn http://www.failuretorefrain.com/jeff/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Jeff Horn writes: > This looks great! I haven't quite read all the code, but I wonder how > this would work on files where bib entries are in their own headline > or mixed into the document ad hoc. Is this designed for a document > with *only* bibtex headlines? > If a headline doesn't have a "type" property, then it will be skipped by the `org-bibtex' function which writes out the .bib file and the `org-bibtex-check' functions. So it should be possible to arbitrarily include/nest bibliography headlines and non-bib headlines in a document. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Eric,
This could be very useful and a significant enhancement to Org-mode
for note taking. With it, library time can be spent almost entirely
within Org-mode, capturing bibliographic information and taking
reading notes. It feels like the right level of functionality--
lightweight and easy to use, with lots of prompting material.
I created an entry with org-bibtex-create and then another with org-
bibtex-read/write. When I ran org-bibtex, only the second entry was
exported. Also, the org-bibtex-read/write process mangled the bibtex
entry a bit, so the resulting .bib file wasn't useful. Note the
addition of {} around the publisher and year, and the truncation of
multi-line entries.
Can I suggest some changes?
1) In our multi-user environment, where several authors are
contributing to a master bibtex file, we depend on the key generating
algorithm of bibtex-mode to help weed out duplicate entries. This
isn't 100% effective, but it catches lots of duplicates and saves us
time. Would it be possible to lift this mechanism and use it in org-
bibtex to generate the CUSTOM_ID?
2) It might be better to use the (generated) key as the Org headline,
instead of the title. Titles can be longer than I find comfortable
for an Org-mode headline, whereas keys are usually about the right
length.
3) org-bibtex-cite seems like a natural next step, especially if it
offers a list of keys in the Org-mode buffer.
Here are the details of my test run:
Existing bibtex entry:
@Book{tuggle94:_cultur_resour_naval_air_station_barber_point,
author ={H. David Tuggle and M. J. Tomonari-Tuggle and
D. Colt Denfeld},
title ={Cultural Resources of Naval Air Station, Barbers
Point: Summary, Assessment, and Inventory Research
Design: Task 1b: Archaeological Research Services
for the Proposed Cleanup, Disposal, and Reuse of
Naval Air Station, Barbers Point, O`ahu, Hawai`i},
publisher =iarii,
year = 1994,
series ={Prepared for Belt Collins Hawaii},
address = {Honolulu},
month = {December}}
Org-mode tree:
* Schulte bibtex
** A journal title
:PROPERTIES:
:type: article
:AUTHOR: A. N. Author
:JOURNAL: Journal of Statistical Software
:YEAR: 1998
:CUSTOM_ID: author_10:article
:END:
** {Cultural Resources of Naval Air Station, Barbers
:PROPERTIES:
:TYPE: book
:CUSTOM_ID: tuggle94:_cultur_resour_naval_air_station_barber_point
:MONTH:December}
:ADDRESS: Honolulu
:SERIES: Prepared for Belt Collins Hawaii
:YEAR: 1994
:PUBLISHER: iarii
:AUTHOR: {H. David Tuggle and M. J. Tomonari-Tuggle and
:END:
Org-bibtex output:
@book{tuggle94:_cultur_resour_naval_air_station_barber_point,
author={{H. David Tuggle and M. J. Tomonari-Tuggle and},
title={{Cultural Resources of Naval Air Station, Barbers},
publisher={iarii},
year={1994},
series={Prepared for Belt Collins Hawaii},
address={Honolulu},
month={December}}
}
hth,
Tom
On Apr 19, 2011, at 1:52 PM, Eric Schulte wrote:
Hi,
In an attempt to organize my reading notes, I've written the following
tool which allows both for exporting Org-mode headlines with bibtex
meta-data to bibtex entries, and for reading existing bibtex entries
into Org-mode headings.
One nice feature of these functions is the ability to check that all
required fields are present in a given headline based on the bibtex
type
(e.g., :article, :inproceedings), and prompt for missing fields.
See the top of the elisp file for more usage information.
https://github.com/eschulte/org-bibtex/blob/master/org-bibtex.el
Cheers -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Cool! Thanks for this. I understand the Fireforg project provides part of this functionality (integrated with Zotero), but this free-standing tool looks helpful. Three quick comments: - I tried to just put this on my load path and require it, but there seems to be a name conflict with the existing org-bibtex.el, which provides for BibTeX links. - Trying to create a book type entry, I get prompted only for `:editor', not for `:author'. - Fireforg namespaces the property names with a `BIB_', e.g. `:BIB_author:', and some people might find that useful as an option. - I'd find it helpful with a user option for org-bibtex-fleshout to prompt for optional fields as well. Yours, Christian On 4/20/11 1:52 AM, Eric Schulte wrote: Hi, In an attempt to organize my reading notes, I've written the following tool which allows both for exporting Org-mode headlines with bibtex meta-data to bibtex entries, and for reading existing bibtex entries into Org-mode headings. One nice feature of these functions is the ability to check that all required fields are present in a given headline based on the bibtex type (e.g., :article, :inproceedings), and prompt for missing fields. See the top of the elisp file for more usage information. https://github.com/eschulte/org-bibtex/blob/master/org-bibtex.el Cheers -- Eric
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Eric, "Eric Schulte" writes: > In an attempt to organize my reading notes, I've written the following > tool which allows both for exporting Org-mode headlines with bibtex > meta-data to bibtex entries, and for reading existing bibtex entries > into Org-mode headings. > > One nice feature of these functions is the ability to check that all > required fields are present in a given headline based on the bibtex type > (e.g., :article, :inproceedings), and prompt for missing fields. > > See the top of the elisp file for more usage information. > https://github.com/eschulte/org-bibtex/blob/master/org-bibtex.el Thanks for announcing this! One note: I believe the name conflicts with a core org-module (org-bibtex.el), which is used to store and open bibtex links. Best, Matt
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
"Thomas S. Dye" writes:
> This could be very useful and a significant enhancement to Org-mode
> for note taking. With it, library time can be spent almost entirely
> within Org-mode, capturing bibliographic information and taking
> reading notes. It feels like the right level of functionality--
> lightweight and easy to use, with lots of prompting material.
>
> I created an entry with org-bibtex-create and then another with org-
> bibtex-read/write. When I ran org-bibtex, only the second entry was
> exported. Also, the org-bibtex-read/write process mangled the bibtex
> entry a bit, so the resulting .bib file wasn't useful. Note the
> addition of {} around the publisher and year, and the truncation of
> multi-line entries.
Just as with auto-generated keys, I wonder whether some of these
problems might be remedied by plugging into existing bibtex-mode
functions, especially bibtex-parse-entry and the bibtex string cleanup
functions. I am always amazed by the ability of bibtex-mode to do the
right thing when cleaning up entries (e.g., remove delimiters from
dates, string abbreviations, etc.).
Also, it might be nice to allow a way to one's existing bibtex entry
type and field definitions---i.e., bibtex-entry-field-alist.
Best,
Mat
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Matt Lundin writes: > Also, it might be nice to allow a way to one's existing bibtex entry ^ use - > type and field definitions---i.e., bibtex-entry-field-alist.
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Tom,
"Thomas S. Dye" writes:
> Hi Eric,
>
> This could be very useful and a significant enhancement to Org-mode
> for note taking. With it, library time can be spent almost entirely
> within Org-mode, capturing bibliographic information and taking
> reading notes. It feels like the right level of functionality--
> lightweight and easy to use, with lots of prompting material.
>
Thanks, I hope so.
>
> I created an entry with org-bibtex-create and then another with org-
> bibtex-read/write. When I ran org-bibtex, only the second entry was
> exported. Also, the org-bibtex-read/write process mangled the bibtex
> entry a bit, so the resulting .bib file wasn't useful. Note the
> addition of {} around the publisher and year, and the truncation of
> multi-line entries.
>
I /believe/ I have fixed this issue. I am now using pre-existing bibtex
functions for reading in entries, and for cleaning up entries written by
org-bibtex.
>
> Can I suggest some changes?
>
> 1) In our multi-user environment, where several authors are
> contributing to a master bibtex file, we depend on the key generating
> algorithm of bibtex-mode to help weed out duplicate entries. This
> isn't 100% effective, but it catches lots of duplicates and saves us
> time. Would it be possible to lift this mechanism and use it in org-
> bibtex to generate the CUSTOM_ID?
>
I've added a new variable `org-bibtex-autogen-keys' which when set to t
will result in auto-generated keys being used instead of prompting the
user to input such keys.
>
> 2) It might be better to use the (generated) key as the Org headline,
> instead of the title. Titles can be longer than I find comfortable
> for an Org-mode headline, whereas keys are usually about the right
> length.
>
Hmm, I would tend to disagree here, but I think it may be a matter of
taste. Note that if you include a TITLE property in a headline then it
will be used instead of the contents of the headline, leaving you free
to put whatever information you want into the headline. I've just
updated the headline creation so that it will create such a title
property as well as using the title as the headline, leaving you free to
subsequently change the headline.
>
> 3) org-bibtex-cite seems like a natural next step, especially if it
> offers a list of keys in the Org-mode buffer.
>
Meaning a function to allow tab-completion on keys... I could see this
being useful but I would imagine that the bib entries would generally
not live in the same buffer as the Org-mode text... rather I'd think
some sort of global registry would be preferable.
Thanks for the suggestions, bug reports, and examples!
Please do let me know if any of these issues remain -- Eric
>
> Here are the details of my test run:
>
> Existing bibtex entry:
>
> @Book{tuggle94:_cultur_resour_naval_air_station_barber_point,
> author ={H. David Tuggle and M. J. Tomonari-Tuggle and
> D. Colt Denfeld},
> title ={Cultural Resources of Naval Air Station, Barbers
> Point: Summary, Assessment, and Inventory Research
> Design: Task 1b: Archaeological Research Services
> for the Proposed Cleanup, Disposal, and Reuse of
> Naval Air Station, Barbers Point, O`ahu, Hawai`i},
> publisher =iarii,
> year = 1994,
> series ={Prepared for Belt Collins Hawaii},
> address = {Honolulu},
> month = {December}}
>
> Org-mode tree:
>
>
> * Schulte bibtex
>
> ** A journal title
>:PROPERTIES:
>:type: article
>:AUTHOR: A. N. Author
>:JOURNAL: Journal of Statistical Software
>:YEAR: 1998
>:CUSTOM_ID: author_10:article
>:END:
>
> ** {Cultural Resources of Naval Air Station, Barbers
>:PROPERTIES:
>:TYPE: book
>:CUSTOM_ID: tuggle94:_cultur_resour_naval_air_station_barber_point
>:MONTH:December}
>:ADDRESS: Honolulu
>:SERIES: Prepared for Belt Collins Hawaii
>:YEAR: 1994
>:PUBLISHER: iarii
>:AUTHOR: {H. David Tuggle and M. J. Tomonari-Tuggle and
>:END:
>
> Org-bibtex output:
>
> @book{tuggle94:_cultur_resour_naval_air_station_barber_point,
> author={{H. David Tuggle and M. J. Tomonari-Tuggle and},
> title={{Cultural Resources of Naval Air Station, Barbers},
> publisher={iarii},
> year={1994},
> series={Prepared for Belt Collins Hawaii},
> address={Honolulu},
> month={December}}
> }
>
> hth,
> Tom
>
> On Apr 19, 2011, at 1:52 PM, Eric Schulte wrote:
>
>> Hi,
>>
>> In an attempt to organize my reading notes, I've written the following
>> tool which allows both for exporting Org-mode headlines with bibtex
>> meta-data to bibtex entries, and for reading existing bibtex entries
>> into Org-mode headings.
>>
>> One nice feature of these functions is the ability to check that all
>> required fields are present in a given headline based on the bibtex
>> type
>> (e.g., :article, :inproceedings), and prompt for missing fields.
>>
>
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Matt Lundin writes:
> "Thomas S. Dye" writes:
>
>> This could be very useful and a significant enhancement to Org-mode
>> for note taking. With it, library time can be spent almost entirely
>> within Org-mode, capturing bibliographic information and taking
>> reading notes. It feels like the right level of functionality--
>> lightweight and easy to use, with lots of prompting material.
>>
>> I created an entry with org-bibtex-create and then another with org-
>> bibtex-read/write. When I ran org-bibtex, only the second entry was
>> exported. Also, the org-bibtex-read/write process mangled the bibtex
>> entry a bit, so the resulting .bib file wasn't useful. Note the
>> addition of {} around the publisher and year, and the truncation of
>> multi-line entries.
>
> Just as with auto-generated keys, I wonder whether some of these
> problems might be remedied by plugging into existing bibtex-mode
> functions, especially bibtex-parse-entry and the bibtex string cleanup
> functions. I am always amazed by the ability of bibtex-mode to do the
> right thing when cleaning up entries (e.g., remove delimiters from
> dates, string abbreviations, etc.).
>
Ah, this is a great suggestions and I wish I had thought to look for
existing support before rolling my own versions of these functions.
org-bibtex is now using both of the functions you mentioned above to
good effect.
>
> Also, it might be nice to allow a way to one's existing bibtex entry
> type and field definitions---i.e., bibtex-entry-field-alist.
>
It shouldn't be difficult to add items to the two defvars used by
org-bibtex to manage bibtex entries, namely bibtex-types and
bibtex-fields
Best -- Eric
>
> Best,
> Mat
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Christian Moe writes: > Cool! Thanks for this. I understand the Fireforg project provides part > of this functionality (integrated with Zotero), but this free-standing > tool looks helpful. Three quick comments: > > - I tried to just put this on my load path and require it, but there > seems to be a name conflict with the existing org-bibtex.el, which > provides for BibTeX links. > Oh, good point, I suppose if this is ever winds up in the contrib directory of Org-mode it will need a name change (although no alternate options immediately jump to mind). In the interim I guess you are best off explicitly loading the file with `load'. > > - Trying to create a book type entry, I get prompted only for > :editor', not for `:author'. > Thanks, this is now fixed. > > - Fireforg namespaces the property names with a `BIB_', > e.g. `:BIB_author:', and some people might find that useful as an > option. > I just added a new variable `org-bibtex-prefix' which could be set to e.g., "BIB_" to use such a name prefix. > > - I'd find it helpful with a user option for org-bibtex-fleshout to > prompt for optional fields as well. > Agreed, when `org-bibtex-check' or `org-bibtex-check-all' are called with a prefix argument, they will call `org-bibtex-fleshout' with an optional argument which will result in the inclusion of optional fields. Best -- Eric > > Yours, > Christian > > > On 4/20/11 1:52 AM, Eric Schulte wrote: >> Hi, >> >> In an attempt to organize my reading notes, I've written the following >> tool which allows both for exporting Org-mode headlines with bibtex >> meta-data to bibtex entries, and for reading existing bibtex entries >> into Org-mode headings. >> >> One nice feature of these functions is the ability to check that all >> required fields are present in a given headline based on the bibtex type >> (e.g., :article, :inproceedings), and prompt for missing fields. >> >> See the top of the elisp file for more usage information. >> https://github.com/eschulte/org-bibtex/blob/master/org-bibtex.el >> >> Cheers -- Eric >> > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Matt Lundin writes: > Hi Eric, > > "Eric Schulte" writes: > >> In an attempt to organize my reading notes, I've written the following >> tool which allows both for exporting Org-mode headlines with bibtex >> meta-data to bibtex entries, and for reading existing bibtex entries >> into Org-mode headings. >> >> One nice feature of these functions is the ability to check that all >> required fields are present in a given headline based on the bibtex type >> (e.g., :article, :inproceedings), and prompt for missing fields. >> >> See the top of the elisp file for more usage information. >> https://github.com/eschulte/org-bibtex/blob/master/org-bibtex.el > > Thanks for announcing this! One note: I believe the name conflicts with > a core org-module (org-bibtex.el), which is used to store and open > bibtex links. > Yes, if this is ever included in the contrib directory of Org, the name will have to be changed, although currently I can't think of a good option. Cheers -- Eric > > Best, > Matt > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Eric,
On Apr 20, 2011, at 9:00 AM, Eric Schulte wrote:
Hi Tom,
"Thomas S. Dye" writes:
Hi Eric,
This could be very useful and a significant enhancement to Org-mode
for note taking. With it, library time can be spent almost entirely
within Org-mode, capturing bibliographic information and taking
reading notes. It feels like the right level of functionality--
lightweight and easy to use, with lots of prompting material.
Thanks, I hope so.
I created an entry with org-bibtex-create and then another with org-
bibtex-read/write. When I ran org-bibtex, only the second entry was
exported. Also, the org-bibtex-read/write process mangled the bibtex
entry a bit, so the resulting .bib file wasn't useful. Note the
addition of {} around the publisher and year, and the truncation of
multi-line entries.
I /believe/ I have fixed this issue. I am now using pre-existing
bibtex
functions for reading in entries, and for cleaning up entries
written by
org-bibtex.
The org-bibtex-read/write process doesn't work on the example I sent.
The read appears to work (though I can't find a buffer *org-bibtex-
entries* afterwards), but the write inserts the headline asterisk then
fails with progn: Wrong type argument: char-or-string-p, nil.
Can I suggest some changes?
1) In our multi-user environment, where several authors are
contributing to a master bibtex file, we depend on the key generating
algorithm of bibtex-mode to help weed out duplicate entries. This
isn't 100% effective, but it catches lots of duplicates and saves us
time. Would it be possible to lift this mechanism and use it in org-
bibtex to generate the CUSTOM_ID?
I've added a new variable `org-bibtex-autogen-keys' which when set
to t
will result in auto-generated keys being used instead of prompting the
user to input such keys.
Beautiful!
2) It might be better to use the (generated) key as the Org headline,
instead of the title. Titles can be longer than I find comfortable
for an Org-mode headline, whereas keys are usually about the right
length.
Hmm, I would tend to disagree here, but I think it may be a matter of
taste. Note that if you include a TITLE property in a headline then
it
will be used instead of the contents of the headline, leaving you free
to put whatever information you want into the headline. I've just
updated the headline creation so that it will create such a title
property as well as using the title as the headline, leaving you
free to
subsequently change the headline.
That sounds right to me. Thanks.
3) org-bibtex-cite seems like a natural next step, especially if it
offers a list of keys in the Org-mode buffer.
Meaning a function to allow tab-completion on keys... I could see
this
being useful but I would imagine that the bib entries would generally
not live in the same buffer as the Org-mode text... rather I'd think
some sort of global registry would be preferable.
I guess it depends on how one uses the software. The use I envision
is for note taking while doing background reading for a project.
First, enter a reference with org-bibtex-create, then take notes while
reading, and finally write a summary that might later be used in the
project document. At this stage, org-bibtex hasn't been called, so
the only place the key is present is in the Org-mode buffer.
Inserting a reference then involves jumping back to the headline,
opening the properties drawer, selecting the value of CUSTOM_ID,
navigating back to the reference point and pasting in the key. A
function that collects keys and then presents them in a list like the
one used to choose TYPE would make this process very easy.
Do you mind my asking what your workflow is with org-bibtex?
All the best,
Tom
Thanks for the suggestions, bug reports, and examples!
Please do let me know if any of these issues remain -- Eric
Here are the details of my test run:
Existing bibtex entry:
@Book{tuggle94:_cultur_resour_naval_air_station_barber_point,
author ={H. David Tuggle and M. J. Tomonari-Tuggle and
D. Colt Denfeld},
title ={Cultural Resources of Naval Air Station, Barbers
Point: Summary, Assessment, and Inventory Research
Design: Task 1b: Archaeological Research Services
for the Proposed Cleanup, Disposal, and Reuse of
Naval Air Station, Barbers Point, O`ahu, Hawai`i},
publisher =iarii,
year = 1994,
series ={Prepared for Belt Collins Hawaii},
address = {Honolulu},
month = {December}}
Org-mode tree:
* Schulte bibtex
** A journal title
:PROPERTIES:
:type: article
:AUTHOR: A. N. Author
:JOURNAL: Journal of Statistical Software
:YEAR: 1998
:CUSTOM_ID: author_10:article
:END:
** {Cultural Resources of Naval Air Station, Barbers
:PROPERTIES:
:TYPE: book
:CUSTOM_ID: tuggle94:_cultur_resour_naval_air_station_barber_point
:MONTH:
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
"Thomas S. Dye" writes:
> Hi Eric,
>
> On Apr 20, 2011, at 9:00 AM, Eric Schulte wrote:
>
>> Hi Tom,
>>
>> "Thomas S. Dye" writes:
>>
>>> Hi Eric,
>>>
>>> This could be very useful and a significant enhancement to Org-mode
>>> for note taking. With it, library time can be spent almost entirely
>>> within Org-mode, capturing bibliographic information and taking
>>> reading notes. It feels like the right level of functionality--
>>> lightweight and easy to use, with lots of prompting material.
>>>
>>
>> Thanks, I hope so.
>>
>>>
>>> I created an entry with org-bibtex-create and then another with org-
>>> bibtex-read/write. When I ran org-bibtex, only the second entry was
>>> exported. Also, the org-bibtex-read/write process mangled the bibtex
>>> entry a bit, so the resulting .bib file wasn't useful. Note the
>>> addition of {} around the publisher and year, and the truncation of
>>> multi-line entries.
>>>
>>
>> I /believe/ I have fixed this issue. I am now using pre-existing
>> bibtex
>> functions for reading in entries, and for cleaning up entries
>> written by
>> org-bibtex.
>>
>
> The org-bibtex-read/write process doesn't work on the example I sent.
> The read appears to work (though I can't find a buffer *org-bibtex-
> entries* afterwards), but the write inserts the headline asterisk then
> fails with progn: Wrong type argument: char-or-string-p, nil.
>
Hmm, I can't re-create this error, the read and write work for me...
Are you placing the point immediately before the bibtex entry before
calling org-bibtex-read?
After calling the read, does the `*org-bibtex-entries*' variable appear
to hold the information for the bibtex entry?
Could you set `debug-on-error' to t, and then send me the entire error
backtrace so I could see where this is going wrong?
>
>>>
>>> Can I suggest some changes?
>>>
>>> 1) In our multi-user environment, where several authors are
>>> contributing to a master bibtex file, we depend on the key generating
>>> algorithm of bibtex-mode to help weed out duplicate entries. This
>>> isn't 100% effective, but it catches lots of duplicates and saves us
>>> time. Would it be possible to lift this mechanism and use it in org-
>>> bibtex to generate the CUSTOM_ID?
>>>
>>
>> I've added a new variable `org-bibtex-autogen-keys' which when set to
>> t will result in auto-generated keys being used instead of prompting
>> the user to input such keys.
>>
>
> Beautiful!
>
>>>
>>> 2) It might be better to use the (generated) key as the Org headline,
>>> instead of the title. Titles can be longer than I find comfortable
>>> for an Org-mode headline, whereas keys are usually about the right
>>> length.
>>>
>>
>> Hmm, I would tend to disagree here, but I think it may be a matter of
>> taste. Note that if you include a TITLE property in a headline then
>> it will be used instead of the contents of the headline, leaving you
>> free to put whatever information you want into the headline. I've
>> just updated the headline creation so that it will create such a
>> title property as well as using the title as the headline, leaving
>> you free to subsequently change the headline.
>>
>
> That sounds right to me. Thanks.
>
>>>
>>> 3) org-bibtex-cite seems like a natural next step, especially if it
>>> offers a list of keys in the Org-mode buffer.
>>>
>>
>> Meaning a function to allow tab-completion on keys... I could see
>> this
>> being useful but I would imagine that the bib entries would generally
>> not live in the same buffer as the Org-mode text... rather I'd think
>> some sort of global registry would be preferable.
>>
>
> I guess it depends on how one uses the software. The use I envision
> is for note taking while doing background reading for a project.
> First, enter a reference with org-bibtex-create, then take notes while
> reading, and finally write a summary that might later be used in the
> project document. At this stage, org-bibtex hasn't been called, so
> the only place the key is present is in the Org-mode buffer.
> Inserting a reference then involves jumping back to the headline,
> opening the properties drawer, selecting the value of CUSTOM_ID,
> navigating back to the reference point and pasting in the key. A
> function that collects keys and then presents them in a list like the
> one used to choose TYPE would make this process very easy.
>
> Do you mind my asking what your workflow is with org-bibtex?
>
Currently I'm just using org-bibtex to collect all of my scattered
reading notes into a single monolithic .org file, but I anticipate
dumping out .bib files from here when writing in the future.
I do see how an automated method of collecting bibtex keys, and then
offering a tab-completing insertion could be useful... I'll make a note
to this effect in my task file for org-bibtex.
Best -- Eric
>
> All the best,
> Tom
>> Thanks for the suggestions, bug reports, and examples!
>>
>> Please do let me know if any of these issues remain -- Eric
>>
>>>
>>> Here are th
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Eric,
After tests on a variety of bibtex entries, using both point before
the entry and selecting an entry, I can't reproduce the problem I had
late the other night with org-bibtex-read/write. Perhaps it was user
error :(
Also, thanks for the text file patch. My mail client and git am don't
seem to cooperate.
I have a library session scheduled next week and am looking forward to
taking my reading notes, including bibtex entries, entirely with Org-
mode.
All the best,
Tom
On Apr 21, 2011, at 11:06 AM, Eric Schulte wrote:
"Thomas S. Dye" writes:
Hi Eric,
On Apr 20, 2011, at 9:00 AM, Eric Schulte wrote:
Hi Tom,
"Thomas S. Dye" writes:
Hi Eric,
This could be very useful and a significant enhancement to Org-mode
for note taking. With it, library time can be spent almost
entirely
within Org-mode, capturing bibliographic information and taking
reading notes. It feels like the right level of functionality--
lightweight and easy to use, with lots of prompting material.
Thanks, I hope so.
I created an entry with org-bibtex-create and then another with
org-
bibtex-read/write. When I ran org-bibtex, only the second entry
was
exported. Also, the org-bibtex-read/write process mangled the
bibtex
entry a bit, so the resulting .bib file wasn't useful. Note the
addition of {} around the publisher and year, and the truncation of
multi-line entries.
I /believe/ I have fixed this issue. I am now using pre-existing
bibtex
functions for reading in entries, and for cleaning up entries
written by
org-bibtex.
The org-bibtex-read/write process doesn't work on the example I sent.
The read appears to work (though I can't find a buffer *org-bibtex-
entries* afterwards), but the write inserts the headline asterisk
then
fails with progn: Wrong type argument: char-or-string-p, nil.
Hmm, I can't re-create this error, the read and write work for me...
Are you placing the point immediately before the bibtex entry before
calling org-bibtex-read?
After calling the read, does the `*org-bibtex-entries*' variable
appear
to hold the information for the bibtex entry?
Could you set `debug-on-error' to t, and then send me the entire error
backtrace so I could see where this is going wrong?
Can I suggest some changes?
1) In our multi-user environment, where several authors are
contributing to a master bibtex file, we depend on the key
generating
algorithm of bibtex-mode to help weed out duplicate entries. This
isn't 100% effective, but it catches lots of duplicates and saves
us
time. Would it be possible to lift this mechanism and use it in
org-
bibtex to generate the CUSTOM_ID?
I've added a new variable `org-bibtex-autogen-keys' which when set
to
t will result in auto-generated keys being used instead of prompting
the user to input such keys.
Beautiful!
2) It might be better to use the (generated) key as the Org
headline,
instead of the title. Titles can be longer than I find comfortable
for an Org-mode headline, whereas keys are usually about the right
length.
Hmm, I would tend to disagree here, but I think it may be a matter
of
taste. Note that if you include a TITLE property in a headline then
it will be used instead of the contents of the headline, leaving you
free to put whatever information you want into the headline. I've
just updated the headline creation so that it will create such a
title property as well as using the title as the headline, leaving
you free to subsequently change the headline.
That sounds right to me. Thanks.
3) org-bibtex-cite seems like a natural next step, especially if it
offers a list of keys in the Org-mode buffer.
Meaning a function to allow tab-completion on keys... I could see
this
being useful but I would imagine that the bib entries would
generally
not live in the same buffer as the Org-mode text... rather I'd think
some sort of global registry would be preferable.
I guess it depends on how one uses the software. The use I envision
is for note taking while doing background reading for a project.
First, enter a reference with org-bibtex-create, then take notes
while
reading, and finally write a summary that might later be used in the
project document. At this stage, org-bibtex hasn't been called, so
the only place the key is present is in the Org-mode buffer.
Inserting a reference then involves jumping back to the headline,
opening the properties drawer, selecting the value of CUSTOM_ID,
navigating back to the reference point and pasting in the key. A
function that collects keys and then presents them in a list like the
one used to choose TYPE would make this process very easy.
Do you mind my asking what your workflow is with org-bibtex?
Currently I'm just using org-bibtex to collect all of my scattered
reading notes into a single monolithic .org file, but I anticipate
dumping out .bib files from here when writing in the future.
I do see how an automated method of colle
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Some notes on initially trying out this new tool. I have some reservations
as to whether it use it. There are certain good reasons in its favor.
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.
The need to represent the bibtex database entry as a PROPERTY list would
appear to me to limit its usefulness to me.
A nit: I would prefer to be free to enter any optional field type I wished,
when I am entering the data. Of course, the tool as it stands helped me to
filter out duplicate fields and unused optional fields from the one bibtex
entry I tried using org-bibtex-read: the output of org-bibtex-write was
cleaner, and correctly incorporated aligning tabs where I'd carelessly left
them out.)
My INPUT ENTRY
@INCOLLECTION{AED-IER-CR,
author = {Junior Noitall},
title = {Specific disruption strategies},
booktitle = {How to annoy the teacher},
publisher = {Noitall Notes},
year = {2011},
editor = {Senior Noitall},
chapter = {13},
pages = {218--243},
address = {Concentric Orbit},
altauthor = {John Smith},
alteditor = {Carl Pumpkin},
isbn = {1-853-31-9},
optaddress = {Room X777},
optpages = {\frac{1}{2}}
}
In the following output, the isbn field is missing.
OUTPUT from org-bibtex-write
@incollection{AED-IER-CR,
author = {Junior Noitall},
title = {Specific disruption strategies},
booktitle = {How to annoy the teacher},
publisher = {Noitall Notes},
year = 2011,
editor = {Senior Noitall},
type = {incollection},
chapter = 13,
pages = {218--243},
address = {Concentric Orbit}
}
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. Somewhere
there is code that does that. It would be a huge and excellent addition to
be able to pass other types, while checking for proper formatting. Bibtex
itself, and the .bst files (at least for bibtex itself; I don't know about
biblatex, etc.) will cherry pick the needed fields. Am I wrong about
this?
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).
Alan Davis
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
"Alan E. Davis" 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
cb2Bib?
> 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?... :)
Best,
Matt
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
"Alan E. Davis" writes:
> Some notes on initially trying out this new tool. I have some reservations
> as to whether it use it. There are certain good reasons in its favor.
>
> 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.
>
Org-bibtex can be used to collect bibtex entries from .bib files, and
(with this most recent attached version) directly from the clipboard
with `org-bibtex-yank'.
Is there a more natural way that this could integrate with external
tools like cb2bib? I've just now installed cb2bib, and I'm not sure I
fully grasp its usage.
>
> The need to represent the bibtex database entry as a PROPERTY list would
> appear to me to limit its usefulness to me.
>
in any particular way?
>
> A nit: I would prefer to be free to enter any optional field type I wished,
> when I am entering the data.
It is possible to add arbitrary properties to a headline with
`org-set-property'. Or you could customize the variables holding bibtex
field and entry types. For example to add a personal :mynotes field to
every bibtex type just execute the following elisp code (or add it to
your configuration). You will then be prompted for a mynotes field on
every bibtex entry. You could also change the :required keyword to add
your field as an option field.
#+begin_src emacs-lisp
(dolist (type org-bibtex-types)
(push :mynotes (cdr (assoc :required (cdr type)
(push (cons :mynotes "My personal field for notes") org-bibtex-fields)
#+end_src
> Of course, the tool as it stands helped me to filter out duplicate
> fields and unused optional fields from the one bibtex entry I tried
> using org-bibtex-read: the output of org-bibtex-write was cleaner, and
> correctly incorporated aligning tabs where I'd carelessly left them
> out.)
>
This functionality is all due to the formatting functions provided by
the existing bibtex.el package.
>
> My INPUT ENTRY
>
> @INCOLLECTION{AED-IER-CR,
> author = {Junior Noitall},
> title = {Specific disruption strategies},
> booktitle = {How to annoy the teacher},
> publisher = {Noitall Notes},
> year = {2011},
> editor = {Senior Noitall},
> chapter = {13},
> pages = {218--243},
> address = {Concentric Orbit},
> altauthor = {John Smith},
> alteditor = {Carl Pumpkin},
> isbn = {1-853-31-9},
> optaddress = {Room X777},
> optpages = {\frac{1}{2}}
> }
>
> In the following output, the isbn field is missing.
>
> OUTPUT from org-bibtex-write
>
> @incollection{AED-IER-CR,
> author = {Junior Noitall},
> title = {Specific disruption strategies},
> booktitle = {How to annoy the teacher},
> publisher = {Noitall Notes},
> year = 2011,
> editor = {Senior Noitall},
> type = {incollection},
> chapter = 13,
> pages = {218--243},
> address = {Concentric Orbit}
> }
>
>
> 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?
If a type is added as with the code given above, then it will be
exported to .bib files along with the default fields.
> I think the emacs bibtex-mode may recognize erroneous bibtex entries.
> Somewhere there is code that does that.
I do not know if bibtex-mode does that or not. I think that bibtex
itself is supposed to simply ignore any fields which it does not
recognize allowing extensibility.
> It would be a huge and excellent addition to be able to pass other
> types, while checking for proper formatting. Bibtex itself, and the
> .bst files (at least for bibtex itself; I don't know about biblatex,
> etc.) will cherry pick the needed fields. Am I wrong about this?
>
The above sounds correct to me.
Given that org properties will likely contain non-bibtex content, I
wouldn't want the default behavior to be exporting every property entry
to bibtex. However if the above solution of adding to the
org-bibtex-types/fields variables is not sufficient, it shouldn't be
difficult to change the org-bibtex command so that if it is called with
a prefix argument it will export *all* properties to the .bib file.
>
>
> 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).
>
I think that rather than competing these files may be merging into a
single file (as with the attached patch). However this remains to be
seen.
Thanks for the feedback and suggestions -- Eric
>
>
> Alan Davis
>From c9e76873e346e3eaf0a99c07458dfac28200490b Mon Sep 17 00:0
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Comments below On Sun, Apr 24, 2011 at 10:52 AM, Eric Schulte wrote: > > Is there a more natural way that this could integrate with external > tools like cb2bib? I've just now installed cb2bib, and I'm not sure I > fully grasp its usage. > > I also found cb2Bib pretty opaque when I first installed it. It's not hard to understand the basics, though. Anything in your clipboard is queued up to import into cb2Bib. The easiest way, for example, to import a bibtex database entry from Google Scholar is to highlight the entire entry in the browser with a mouse, and it's parts are already displayed in cb2Bib. If, for example, one is trying to save from a text-based bibliography entry, it may be copied to the clipboard. Highlight, for example, the title, and right click, then select "title". And so on. This is the automagical part that I have found so very useful. It is important to 'unplug' cb2Bib if the entry needs to be edited. If not, any action in the fields and displayed will be lost. Then save using the save icons. I have to say, though, that a little explanation would go a long way, when trying to use it. Once this process is complete, I can see that being able to, in turn copy this entry to the clipboard would indeed be useful with org-bibtex . I wonder if it's possible to set a pipe or one of those cryptic file types (fifo?) I cannot remember would either work, or whether the developers would agree to enabling this ability. Alan
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Matt Lundin writes:
[...]
>> 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.
>
There is already an option for an org-bibtex specific property name
prefix, (namely `org-bibtex-prefix'). Perhaps when this prefix is used,
and the `org-bibtex' functions is called with a prefix argument (note:
entirely different usage of the term "prefix") then only entries which
begin with the `org-bibtex-prefix' would be exported... I believe that
should provide a natural way for arbitrary fields to pass through
org-bibtex without the user needing to explicitly name them, or there
being any danger of contamination from existing org-mode properties.
>
>> 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.
>
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. Also, some integration
with the existing org-bibtex linking functions (as you've mentioned)
would probably address some of Tom's earlier requests for an easy means
of inserting bibtex entries.
The only question now is the one which originally lead me to simply dump
this into org-bibtex, namely, what is a good name? The first options
that occur to me are
- org-bib
- org-reference
- org-cite
What do you think? Any better suggestions?
Thanks -- Eric
>
> Wishful thinking?... :)
>
> Best,
> Matt
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
"Alan E. Davis" writes: [...] > > Once this process is complete, I can see that being able to, in turn copy > this entry to the clipboard would indeed be useful with org-bibtex . I > wonder if it's possible to set a pipe or one of those cryptic file types > (fifo?) I cannot remember would either work, or whether the developers would > agree to enabling this ability. > It sounds like asking the cb2bib developers to either automatically copy completed entries to the clipboard, or to add a button implementing this behavior would be ideal. Barring that there is an existing xclip utility (on debian: apt-get install xclip) which allows for piping data to the clipboard, e.g. with cat ~/references.bib |xclip -selection clipboard will copy the entirety of the references.bib file to the clipboard. As for using xclip to automatically copy any changes to a file to the clipboard, I'm not sure if that is possible, but this may be useful [1]. Best -- Eric Footnotes: [1] http://www.howtoforge.com/triggering-commands-on-file-or-directory-changes-with-incron -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
On 4/24/11 4:21 PM, Eric Schulte wrote: Matt Lundin 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
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
On Mon, Apr 25, 2011 at 12:29 AM, Eric Schulte wrote: > > It sounds like asking the cb2bib developers to either automatically copy > completed entries to the clipboard, or to add a button implementing this > behavior would be ideal. Indeed, this is about what cb2Bib does, to a good extent, depending on the nature of the reference. A simple text reference, like S J Hickson. On the Sexual Cells and the Early Stages in the Development of Millepora plicata. Philosophical Transactions of the Royal Society of London. B 179, 193 - 204 (1888). may not completely be resolved (not sure in this case): the template on cb2Bib will be partially filled in, and it may require a couple of quick steps to complete the template and save. Unplugging, one may then enter the abstract or other fields, then save. > cat ~/references.bib |xclip -selection clipboard > > will copy the entirety of the references.bib file to the clipboard. > > This is good. Thank you. This will certainly be helpful in some cases. The case for cb2Bib is somewhat different, as once the template is filled in, one may save it to .bib file, and one may select which file. If one were able to use a pipe, xclip, or a fifo file, perhaps this could be made immediately available to org-bibtex-read. Alan
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Eric and Christian, Christian Moe writes: > 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. Christian, you are right. I stand corrected. I agree that the namespace can accommodate import/export/conversion features in addition to hyperlinking. Apologies (especially to Eric) for my wavering on where to put this. This functionality is indeed not a generic bib backend, but rather tightly integrated with bibtex-mode and the bibtex format. So a full +1 for adding this to org-bibtex.el. And that's my final answer... :) >> 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. Agreed. Best, Matt
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
"Alan E. Davis" writes: [...] >> cat ~/references.bib |xclip -selection clipboard >> >> will copy the entirety of the references.bib file to the clipboard. >> >> This is good. Thank you. This will certainly be helpful in some cases. > > The case for cb2Bib is somewhat different, as once the template is filled > in, one may save it to .bib file, and one may select which file. If one > were able to use a pipe, xclip, or a fifo file, perhaps this could be made > immediately available to org-bibtex-read. > With the `org-bibtex-yank' function mentioned (briefly) in one of my previous responses, it is possible to read directly from the top of the kill ring, which (assuming your kill ring is integrated with your clipboard --- which is the case for me, but I don't know if it is a common setup) means that entries can be "yanked" directly from your clipboard into an Org-mode file as a headline. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Matt Lundin writes: > Hi Eric and Christian, > > Christian Moe writes: > >> 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. > > Christian, you are right. I stand corrected. I agree that the namespace > can accommodate import/export/conversion features in addition to > hyperlinking. > > Apologies (especially to Eric) for my wavering on where to put this. > This functionality is indeed not a generic bib backend, but rather > tightly integrated with bibtex-mode and the bibtex format. So a full +1 > for adding this to org-bibtex.el. And that's my final answer... :) > No problem here, this is the sort of question I'm happy to defer on, especially as it shouldn't really affect the final functionality. Given that I hadn't yet started to extract the code this is no skin off my nose. I'll go ahead and leave this code where it is. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Eric,
"Eric Schulte" writes:
> Matt Lundin writes:
>
> [...]
>>> 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.
>
> There is already an option for an org-bibtex specific property name
> prefix, (namely `org-bibtex-prefix'). Perhaps when this prefix is used,
> and the `org-bibtex' functions is called with a prefix argument (note:
> entirely different usage of the term "prefix") then only entries which
> begin with the `org-bibtex-prefix' would be exported... I believe that
> should provide a natural way for arbitrary fields to pass through
> org-bibtex without the user needing to explicitly name them, or there
> being any danger of contamination from existing org-mode properties.
I went ahead and implemented this. (Alas, it meant cluttering up your
very elegant org-bibtex-headline with another mapcar.)
Assuming that not all users who use a prefix will want to export
arbitrary fields, I made the functionality dependent on two variables:
org-bibtex-prefix and a org-bibtex-export-arbitrary-fields. But this
could be simplified.
I also made the key property configurable.
The patch was created against a patched org-bibtex.el, so I will wait
until your changes get merged into the repo before sending a formal
patch. But I thought I'd send it along to see if you think the changes
are appropriate.
Best,
Matt
--8<---cut here---start->8---
diff --git a/lisp/org-bibtex.el b/lisp/org-bibtex.el
index 9ee30f1..afa3764 100644
--- a/lisp/org-bibtex.el
+++ b/lisp/org-bibtex.el
@@ -221,6 +221,24 @@ For example setting to 'BIB_' would allow interoperability
with fireforg."
:group 'org-bibtex
:type 'string)
+(defcustom org-bibtex-export-arbitrary-fields nil
+ "When converting to bibtex allow fields not defined in `org-bibtex-fields'.
+This only has effect if org-bibtex-prefix is defined, so as to
+ensure that other org-properties, such as CATEGORY or LOGGING are
+not placed in the exported bibtex entry."
+ :group 'org-bibtex
+ :type 'boolean)
+
+;; TODO if ID, test to make sure ID is unique
+(defcustom org-bibtex-key-property "CUSTOM_ID"
+ "Property that holds the bibtex key.
+By default, this is CUSTOM_ID, which enables easy linking to
+bibtex headlines from within an org file. This can be set to ID
+to enable global links, but only with great caution, as global
+IDs must be unique."
+ :group 'org-bibtex
+ :type 'string)
+
;;; Utility functions
(defun org-bibtex-get (property)
@@ -232,7 +250,7 @@ For example setting to 'BIB_' would allow interoperability
with fireforg."
(substring (symbol-name property) 1)
property
(org-set-property
- (concat (unless (string= "CUSTOM_ID" prop) org-bibtex-prefix) prop)
+ (concat (unless (string= org-bibtex-key-property prop) org-bibtex-prefix)
prop)
value)))
(defun org-bibtex-headline ()
@@ -246,7 +264,7 @@ For example setting to 'BIB_' would allow interoperability
with fireforg."
(if (listp e) (apply #'flatten e) (list
e)))
lsts
(let ((notes (buffer-string))
- (id (org-bibtex-get "custom_id"))
+ (id (org-bibtex-get org-bibtex-key-property))
(type (org-bibtex-get "type")))
(when type
(let ((entry (format
@@ -254,15 +272,23 @@ For example setting to 'BIB_' would allow
interoperability with fireforg."
(mapconcat
(lambda (pair) (format " %s={%s}" (car pair) (cdr
pair)))
(remove nil
-(mapcar
- (lambda (field)
- (let ((value (or (org-bibtex-get (from-k field))
-(and (equal :title field)
- (org-get-heading)
- (when value (cons (from-k field) value
- (flatten
- (get :required (get (to-k type) org-bibtex-
Re: [O] [ANN] org-bibtex.el --- convert between Org headings and bibtex entries
Hi Matt,
Matt Lundin writes:
> Hi Eric,
>
> "Eric Schulte" writes:
>
>> Matt Lundin writes:
>>
>> [...]
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.
>>
>> There is already an option for an org-bibtex specific property name
>> prefix, (namely `org-bibtex-prefix'). Perhaps when this prefix is used,
>> and the `org-bibtex' functions is called with a prefix argument (note:
>> entirely different usage of the term "prefix") then only entries which
>> begin with the `org-bibtex-prefix' would be exported... I believe that
>> should provide a natural way for arbitrary fields to pass through
>> org-bibtex without the user needing to explicitly name them, or there
>> being any danger of contamination from existing org-mode properties.
>
> I went ahead and implemented this. (Alas, it meant cluttering up your
> very elegant org-bibtex-headline with another mapcar.)
>
This looks great thanks.
>
> Assuming that not all users who use a prefix will want to export
> arbitrary fields, I made the functionality dependent on two variables:
> org-bibtex-prefix and a org-bibtex-export-arbitrary-fields. But this
> could be simplified.
>
I think this is the best approach.
>
> I also made the key property configurable.
>
Nice, I think this is also an improvement.
>
> The patch was created against a patched org-bibtex.el, so I will wait
> until your changes get merged into the repo before sending a formal
> patch. But I thought I'd send it along to see if you think the changes
> are appropriate.
>
Oh, I should have read this last paragraph.
Having received confirmation from Bastien that it was alright to include
this code into org-bibtex in the core, I have applied your patch on top
of my own patches. The results are now in the Org-mode git repository.
Please do let me know if anything looks amiss --- I mainly just expanded
your patch to take into account my intervening changes, and to avoid
lines longer than 80 characters.
Thanks! -- Eric
>
> Best,
> Matt
>
> diff --git a/lisp/org-bibtex.el b/lisp/org-bibtex.el
> index 9ee30f1..afa3764 100644
> --- a/lisp/org-bibtex.el
> +++ b/lisp/org-bibtex.el
> @@ -221,6 +221,24 @@ For example setting to 'BIB_' would allow
> interoperability with fireforg."
>:group 'org-bibtex
>:type 'string)
>
> +(defcustom org-bibtex-export-arbitrary-fields nil
> + "When converting to bibtex allow fields not defined in `org-bibtex-fields'.
> +This only has effect if org-bibtex-prefix is defined, so as to
> +ensure that other org-properties, such as CATEGORY or LOGGING are
> +not placed in the exported bibtex entry."
> + :group 'org-bibtex
> + :type 'boolean)
> +
> +;; TODO if ID, test to make sure ID is unique
> +(defcustom org-bibtex-key-property "CUSTOM_ID"
> + "Property that holds the bibtex key.
> +By default, this is CUSTOM_ID, which enables easy linking to
> +bibtex headlines from within an org file. This can be set to ID
> +to enable global links, but only with great caution, as global
> +IDs must be unique."
> + :group 'org-bibtex
> + :type 'string)
> +
>
> ;;; Utility functions
> (defun org-bibtex-get (property)
> @@ -232,7 +250,7 @@ For example setting to 'BIB_' would allow
> interoperability with fireforg."
>(substring (symbol-name property) 1)
> property
> (org-set-property
> - (concat (unless (string= "CUSTOM_ID" prop) org-bibtex-prefix) prop)
> + (concat (unless (string= org-bibtex-key-property prop)
> org-bibtex-prefix) prop)
> value)))
>
> (defun org-bibtex-headline ()
> @@ -246,7 +264,7 @@ For example setting to 'BIB_' would allow
> interoperability with fireforg."
> (if (listp e) (apply #'flatten e) (list
> e)))
> lsts
> (let ((notes (buffer-string))
> - (id (org-bibtex-get "custom_id"))
> + (id (org-bibtex-get org-bibtex-key-property))
>(type (org-bibtex-get "type")))
>(when type
> (let ((entry (format
> @@ -254,15 +27
