Re: [wip-cite-new] Merging tomorrow?
On Friday, 20 Aug 2021 at 09:47, Bruce D'Arcus wrote: > Though for ODT, you might want to look into oc-csl; citeproc-el just > got improved ODF support. So I decided to try this out. Not working for me, but early days in debugging. For some reason, when I export to ODT, the "format" for the export is "org" and not "org-odt" in citeproc, specifically in the call to =citeproc-formatter-for-format=. I haven't figured out how this format is set; early days, as I said. It's now the weekend and I need a break but if I learn anything, I'll update on the list. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-628-g366444 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
On Fri, Aug 20, 2021 at 11:21 AM John Kitchin wrote: > I think bibtex-completion is agnostic of ivy or helm, and doesn't require > either of them to work. You can use it for candidates to selectrum if you > want, and the other many features it offers for notes, pdf, etc... Sorry; meant to send that off-list. But yes, to clarify: bibtex-completion is independent of the frontend. I was mostly removing my dependency on it to get some of the benefits of the new parsebib release (namely CSL JSON support), and because I had some ideas I wanted to explore. But in any case, bibtex-completion provides no front-end; you still need a completing-read function for that, and I think bibtex-actions provides a good one. Also, you need to wrap it's functions to get interactive commands.
Re: [wip-cite-new] Merging tomorrow?
I think bibtex-completion is agnostic of ivy or helm, and doesn't require either of them to work. You can use it for candidates to selectrum if you want, and the other many features it offers for notes, pdf, etc... On Fri, Aug 20, 2021 at 11:07 AM Bruce D'Arcus wrote: > I think so. > > I actually just started the process of removing the bibtex-completion > dependency. > > Give it a try in any case. It should work well with org-cite, and you > can even use pieces of org-ref-cite if you prefer that to my > (currently) more minimal embark-based approach. > > On Fri, Aug 20, 2021 at 10:53 AM Eric S Fraga wrote: > > > > Bruce, > > > > off-list, I notice that bibtex-actions has been updated. I have been > > using bibtex-completions but as I now longer use either ivy or helm, > > having switched to selectrum, I should probably switch to your > > package. Would this be a correct view/conclusion? > > > > Thank you, > > eric > > > > -- > > : Professor Eric S Fraga > > : Fresa black box optimization: doi:10.5281/zenodo.5045812 > > : PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D > > > > Latest publications: doi:10.3303/CET2186011 & arxiv:2106.05096 > >
Re: [wip-cite-new] Merging tomorrow?
I think so. I actually just started the process of removing the bibtex-completion dependency. Give it a try in any case. It should work well with org-cite, and you can even use pieces of org-ref-cite if you prefer that to my (currently) more minimal embark-based approach. On Fri, Aug 20, 2021 at 10:53 AM Eric S Fraga wrote: > > Bruce, > > off-list, I notice that bibtex-actions has been updated. I have been > using bibtex-completions but as I now longer use either ivy or helm, > having switched to selectrum, I should probably switch to your > package. Would this be a correct view/conclusion? > > Thank you, > eric > > -- > : Professor Eric S Fraga > : Fresa black box optimization: doi:10.5281/zenodo.5045812 > : PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D > > Latest publications: doi:10.3303/CET2186011 & arxiv:2106.05096
Re: [wip-cite-new] Merging tomorrow?
On Friday, 20 Aug 2021 at 09:47, Bruce D'Arcus wrote: > Though for ODT, you might want to look into oc-csl; citeproc-el just > got improved ODF support. Thank you for the heads up on this. Looks promising for those that regularly export to ODT! In my case, I just need a quick and dirty draft so that I can get the core of the text into a Word document being worked on by several people. I hate writing in a word processor (my fingers just know Emacs so I often end up deleting whole sections of text when I type C-x... not to mention C-q ;-)) so prefer doing the bulk of the writing in org. Once in the Word document, references etc. will be re-formatted manually by others. Thanks again, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-625-ge7454c : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
Though for ODT, you might want to look into oc-csl; citeproc-el just got improved ODF support. https://github.com/andras-simonyi/citeproc-el/pull/45 On Fri, Aug 20, 2021 at 9:46 AM Eric S Fraga wrote: > > Ignore my question. The following works (had to look at the source, > which I should have done in the first place, of course ): > > #+cite_export: basic numeric nb > > Thank you and back to your normal programme ... ;-) > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-625-ge7454c > : Latest paper written in org: https://arxiv.org/abs/2106.05096 >
Re: [wip-cite-new] Merging tomorrow?
Ignore my question. The following works (had to look at the source, which I should have done in the first place, of course ): #+cite_export: basic numeric nb Thank you and back to your normal programme ... ;-) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-625-ge7454c : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
Hello all, A quick question: I am exporting to ODT and am happy with the basic cite exporter. I want numeric citations. Does oc-basic allow me to somehow specify that the reference (in the text) be numeric by default and not authors and year? I can use [@cite/nb:...] with #+cite-export: basic numeric but if I forget the /nb, I get (author year) in the text. Am I missing something obvious? The documentation is obviously still lacking (not a complaint, just reality). Thank you, eric PS - I normally export to LaTeX which is working just fine, by the way! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-625-ge7454c : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
Is there a timeline for when this will be available in orgmode.org/elpa or
other package repository? I tried it today, but it doesn't seem to be there
yet, at least not in this version:
Org mode version 9.4.6 (9.4.6-10-gee652a-elpaplus @
/Users/jkitchin/Dropbox/emacs/scimax/elpa/org-plus-contrib-20210712/)
John
---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Wed, Jul 7, 2021 at 8:18 PM Nicolas Goaziou
wrote:
> Hello,
>
> I think the "wip-cite-new" branch is in good shape now. As
> a consequence, I'd like to merge it tomorrow.
>
> It is documented, but the documentation is scattered across the various
> "oc" libraries, and some threads in the mailing list. I'll do a summary
> here, from a user point of view.
>
> --8<---cut here---start->8---
> Basically, in order to use it, you need to first set-up a bibliography,
> using one or more "bibliography" keywords. on such a keyword
> visits the related file. Out of the box, Org supports JSON-CSL and
> BibTeX (or biblatex) bibliographies.
>
> Then, citations can be inserted with the following syntax:
>
> [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
>
> Spaces are meaningful except those after the initial colon and before
> the closing bracket.
>
> Every part of the syntax is optional, except the brackets, "cite" and
> the colon. Also the citation must contain at least a key. So its minimal
> form is:
>
> [cite:@key]
>
> The "style" part is detailed below, in the part related to export.
>
> Org can insert or edit citations with (and delete them with
> ), follow them with , fontify them, and export
> them. These four actions (insert, follow, activate, and export) are
> called capabilities. Libraries responsible for these capabilities are
> called citation processors.
>
> You can select one citation processor for each capability, independently
> on the others, through the following variables:
>
> - org-cite-activate-processor
> - org-cite-export-processors
> - org-cite-follow-processor
> - org-cite-insert-processor
>
> Out of the box, Org provides the "basic" (in "oc-basic.el") processor
> for all of these tasks. It also boasts processors dedicated for export:
> "csl", "natbib" and "biblatex".
>
> During export, output for citations is controlled by their style, which
> is an Org label that the export processor may recognize and associate to
> a specific display, or fall-back to a default style (called "nil"). For
> example, most processors support "noauthor" and "text" styles.
>
> Some styles can accept a variant, with the syntax "style/variant".
> Again, it's up to the processor to associate it to a specific display.
> Common variants include "bare", "caps" or "full". They also accept
> short-hands, like "b", "c" and "f". Please refer to the export
> processors' libraries ("oc-basic.el", "oc-csl.el", …) for more information.
>
> It is possible to define a default style for a whole document (with
> "cite_export"), or for all documents (with `org-cite-export-processors').
>
> References are displayed with the "print_bibliography" keyword. It is
> possible to add parameters to its value, as some export processors could
> make use of them.
> --8<---cut here---end--->8---
>
> Please let me know if there are any objections to the merge.
>
> Regards,
> --
> Nicolas Goaziou
>
>
Re: [wip-cite-new] Merging tomorrow?
On Friday, 9 Jul 2021 at 09:36, William Denton wrote: > Is the citation work big enough to move the version number for the > next full release to 10? I guess it doesn't break anything (i.e. fully backwards compatible) so no real need to bump the version number? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-579-gfdb98a : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
Is the citation work big enough to move the version number for the next full release to 10? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator.
Re: [wip-cite-new] Merging tomorrow?
On Friday, 9 Jul 2021 at 15:58, Timothy wrote: > This could be as simple as a way of handling links to named > images/tables/etc. when exporting. Maybe start a new thread, with a clear indication of what is missing in the current version with respect to referencing. I use internal references all the time (to figures, tables, equations) and it works great, at least for LaTeX export. Is it that other export engines don't do what is needed? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-579-gfdb98a : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
Hi Nicolas, In light of all the thoughts expressed on referencing, I no longer think it's a good idea to have referencing capabilities in wip-cite-new. I think referencing should get a bit of attention, as citation has here, but a much smaller separate effort now appears more appropriate to me. This could be as simple as a way of handling links to named images/tables/etc. when exporting. Update: I see wip-cite-new has been merged . Still sending this because I think my sentiment is worth sharing and I'd like to prompt a discussion on references (I'll probably give this a bit of a think then start a new thread in a few days). -- Timothy William Denton writes: > On 8 July 2021, Bruce D'Arcus wrote: > >> And the implementation challenges raised by John Kitchin and Joost >> Kremers (namely the candidate list is different) make this better to >> deal with using a different mechanism. >> >> As a package developer that supports org-cite, I really don't want to >> be worrying about internal references and such. >> >> And as a user, I don't see the benefit of doing so. >> >> Effectively, these seem more like org internal links. > > I agree with all this. Personally, I'd never expect a citation system like > this > to handle internal references. The way librarians think about citations and > referencing, these are different. > > > Bill -- Timothy
Re: [wip-cite-new] Merging tomorrow?
On 8 July 2021, Bruce D'Arcus wrote: And the implementation challenges raised by John Kitchin and Joost Kremers (namely the candidate list is different) make this better to deal with using a different mechanism. As a package developer that supports org-cite, I really don't want to be worrying about internal references and such. And as a user, I don't see the benefit of doing so. Effectively, these seem more like org internal links. I agree with all this. Personally, I'd never expect a citation system like this to handle internal references. The way librarians think about citations and referencing, these are different. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator.
Re: [wip-cite-new] Merging tomorrow?
Timothy writes: > Lastly, an example of what I’d expect when exporting to ascii (with three > example syntaxes): > > ┌ > │ #+name: sometab > │ #+caption: Some table > │ | a | b | > │ | c | d | > │ > │ Hey, look at [[sometab]]. (or) > │ Hey, look at [cite:#sometab]. (or) > │ Hey, look at [ref:sometab]. > └ > > ┌ > │ ━━ > │ a b > │ c d > │ ━━ > │ Table 1: Some table > │ > │ Hey, look at Table 1. > └ I'm still lost, sorry. --8<---cut here---start->8--- #+name: sometab #+caption: Some table | a | b | | c | d | Hey, look at Table [[sometab]]. --8<---cut here---end--->8--- is already exported as --8<---cut here---start->8--- ━━ a b c d ━━ Table 1: Some table Hey, look at Table 1. --8<---cut here---end--->8--- Could you explain what you would like to see, in addition to what is already possible? I think, however, that it is not directly related to citations, unless you want to be able to somehow link to a cite. Then we may have a problem, because there is currently no way to name a cite. However, if that ever makes sense, it is still possible to add a target next to it: <<@key>>[cite:@key]
Re: [wip-cite-new] Merging tomorrow?
On Thu, Jul 8, 2021 at 9:43 AM Timothy wrote: > > Hi Nicolas, > > > At this point, I don’t have enough understanding of the problem to have > > an opinion. IIUC, your example does not even mention citations. How > > should it be used, what should be the output in LaTeX, and in UTF-8 > > export? This is not clear to me. > > > > What can I say however is: if this feature implies to change, or extend, > > syntax, then it is /de facto/ a blocker for the merge, and needs to be > > sorted out. > > This very much depends on how you view references vs citations. I personally > think of references as in-text citations (i.e. you’re citing other bits of the > very same document), but I doubt this is a common view (as suggested by other > replies). I'm glad you raised the question, even if it is a bit late. But I indeed don't think your view is common :-) I decided to take a look at what a canonical guide like Chicago Manual of Style says about this. They call these "text references" (though confusingly, they use the word "references" when discussing citations too). For example, there are headings like "3.9: Text references to numbered illustrations". or "2.30: Formatting text references and callouts to tables and illustrations". And then descriptions like "A text reference is addressed to the reader (“see table 5,” or “fig. 3.2”) and will appear in the published version." Here's some stuff from APA, though they don't go into references much. https://apastyle.apa.org/style-grammar-guidelines/tables-figures/figures And finally, FWIW, MS Word and Open/LibreOffice implement support for this via "cross-references": https://guides.lib.umich.edu/c.php?g=283073=1888264 https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/Writer_Guide/Using_automatic_cross-references So they may be similar, but are not the same. And the implementation challenges raised by John Kitchin and Joost Kremers (namely the candidate list is different) make this better to deal with using a different mechanism. As a package developer that supports org-cite, I really don't want to be worrying about internal references and such. And as a user, I don't see the benefit of doing so. Effectively, these seem more like org internal links. Bruce
Re: [wip-cite-new] Merging tomorrow?
Hi Nicolas, > At this point, I don’t have enough understanding of the problem to have > an opinion. IIUC, your example does not even mention citations. How > should it be used, what should be the output in LaTeX, and in UTF-8 > export? This is not clear to me. > > What can I say however is: if this feature implies to change, or extend, > syntax, then it is /de facto/ a blocker for the merge, and needs to be > sorted out. This very much depends on how you view references vs citations. I personally think of references as in-text citations (i.e. you’re citing other bits of the very same document), but I doubt this is a common view (as suggested by other replies). To try to lay out what one may expect with references, I’d think some support in Org (without org-ref et. al) would be good (at least for exporting) — but I’m not sure what a good for would be. I think it could be treated similarly to citations, given a variant syntax like [] or even just be added as a way of exporting links to named figures/tables (i.e. ). It’s a bit late to bring this up, but in case this should come under the citation umbrella I thought I should. Lastly, an example of what I’d expect when exporting to ascii (with three example syntaxes): ┌ │ #+name: sometab │ #+caption: Some table │ | a | b | │ | c | d | │ │ Hey, look at [[sometab]]. (or) │ Hey, look at [cite:#sometab]. (or) │ Hey, look at [ref:sometab]. └ ┌ │ ━━ │ a b │ c d │ ━━ │ Table 1: Some table │ │ Hey, look at Table 1. └ I hope this clears up what I was thinking. All the best, *Timothy*
Re: [wip-cite-new] Merging tomorrow?
Okay, thank you. I'll have to train myself to use C-c ' in more situations (as I didn't know it would work on #+include etc. lines). -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-579-gfdb98a : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
Hello, Eric S Fraga writes: > Why C-c ' and not C-c C-o to be consistent with the rest of org? For > me, it seems that in the rest of org, C-c ' is for editing something; > C-c C-o is for opening/visiting/following. Good question. is "remote editing", is "follow link". In this situation, I think #+bibliography: somefile.bib is closer from #+include: somefile.org or #+setupfile: config.org than it is from [[file:somefile.org]] So, I do think this is consistent with the rest of Org, actually. Regards, -- Nicolas Goaziou
Re: [wip-cite-new] Merging tomorrow?
On Thursday, 8 Jul 2021 at 02:17, Nicolas Goaziou wrote: > I think the "wip-cite-new" branch is in good shape now. As > a consequence, I'd like to merge it tomorrow. Yes please! I've been using it on and off (having to switch branches) for some time now and it is working very well. It needs to be in master *now*! One point, however: > Basically, in order to use it, you need to first set-up a bibliography, > using one or more "bibliography" keywords. on such a keyword > visits the related file. Why C-c ' and not C-c C-o to be consistent with the rest of org? For me, it seems that in the rest of org, C-c ' is for editing something; C-c C-o is for opening/visiting/following. Not a show-stopper, more of a puzzling choice (to me). Thank you for all the work on this new feature, in any case! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-579-gfdb98a : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
On Thursday, 8 Jul 2021 at 11:47, Timothy wrote: > wip-cite-new deals with citing from bibliographies, but I don't think it > deals with within-document referencing --- should it? Are these not orthogonal activities? Doesn't org already support in-document references? I may be missing something but what you have described has nothing to do with citations. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-579-gfdb98a : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [wip-cite-new] Merging tomorrow?
My intuition is that crossrefs are separate from the citations. In org-ref, they are separate link types like ref:xxx, pageref:xxx. eqref:xxx, etc. They also use a different source of candidates than cites do. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Jul 8, 2021 at 7:16 AM Bruce D'Arcus wrote: > On Thu, Jul 8, 2021 at 6:26 AM Nicolas Goaziou > wrote: > > > > Hello, > > > > Timothy writes: > > > > > Bruce D'Arcus writes: > > > > > >>> wip-cite-new deals with citing from bibliographies, but I don't > think it > > >>> deals with within-document referencing --- should it? > > > > > >> 1. Should it? > > >> 1. Maybe. > > > > > > I feel like it would fit. With everything that's been done for > > > citations, this feels like it may be a rather minor addition (or at > > > least this is what I hope). > > > > > >> 2. Can it? Could the design be extended to include internal > referencing? > > >> 2. I think so. You'd just need a way to include internal targets in > > >> addition to the citation-references (keys); for illustration, > > >> something like [cite:#some-if]. > > > > > > I can't claim to have thought about this that much either, but > something > > > like [cite:#some-fig] would seem to fit. > > > > > >> 3. If yes to both, should that hold back merger now? > > >> 3. No. > > > > > > I don't think this should hold up the merge either, but it's relevant > in > > > the overall nature of the feature and perhaps could be shoehorned in > > > following the merge? I feel like this is one small quite simple case > and > > > most of the thinking required has already been done. I'm not sure > > > though, I'd go with whatever Nic's thought are on this. > > > > At this point, I don't have enough understanding of the problem to have > > an opinion. IIUC, your example does not even mention citations. How > > should it be used, what should be the output in LaTeX, and in UTF-8 > > export? This is not clear to me. > > > > What can I say however is: if this feature implies to change, or extend, > > syntax, then it is /de facto/ a blocker for the merge, and needs to be > > sorted out. > > As I was hinting, I don't know this area well either. > > I think the first question is the "should" one; whether this is > in-scope of this module. > > I wasn't sure, so said "maybe". > > Joost says "no." > > In latex, such internal references are not citations though; they use > a different mechanism. > > Does that not suggest, Timothy, that this might be out-of-scope for > this module; that Joost is right? > > Bruce > >
Re: [wip-cite-new] Merging tomorrow?
On Thu, Jul 8, 2021 at 6:26 AM Nicolas Goaziou wrote: > > Hello, > > Timothy writes: > > > Bruce D'Arcus writes: > > > >>> wip-cite-new deals with citing from bibliographies, but I don't think it > >>> deals with within-document referencing --- should it? > > > >> 1. Should it? > >> 1. Maybe. > > > > I feel like it would fit. With everything that's been done for > > citations, this feels like it may be a rather minor addition (or at > > least this is what I hope). > > > >> 2. Can it? Could the design be extended to include internal referencing? > >> 2. I think so. You'd just need a way to include internal targets in > >> addition to the citation-references (keys); for illustration, > >> something like [cite:#some-if]. > > > > I can't claim to have thought about this that much either, but something > > like [cite:#some-fig] would seem to fit. > > > >> 3. If yes to both, should that hold back merger now? > >> 3. No. > > > > I don't think this should hold up the merge either, but it's relevant in > > the overall nature of the feature and perhaps could be shoehorned in > > following the merge? I feel like this is one small quite simple case and > > most of the thinking required has already been done. I'm not sure > > though, I'd go with whatever Nic's thought are on this. > > At this point, I don't have enough understanding of the problem to have > an opinion. IIUC, your example does not even mention citations. How > should it be used, what should be the output in LaTeX, and in UTF-8 > export? This is not clear to me. > > What can I say however is: if this feature implies to change, or extend, > syntax, then it is /de facto/ a blocker for the merge, and needs to be > sorted out. As I was hinting, I don't know this area well either. I think the first question is the "should" one; whether this is in-scope of this module. I wasn't sure, so said "maybe". Joost says "no." In latex, such internal references are not citations though; they use a different mechanism. Does that not suggest, Timothy, that this might be out-of-scope for this module; that Joost is right? Bruce
Re: [wip-cite-new] Merging tomorrow?
Hello, Timothy writes: > Bruce D'Arcus writes: > >>> wip-cite-new deals with citing from bibliographies, but I don't think it >>> deals with within-document referencing --- should it? > >> 1. Should it? >> 1. Maybe. > > I feel like it would fit. With everything that's been done for > citations, this feels like it may be a rather minor addition (or at > least this is what I hope). > >> 2. Can it? Could the design be extended to include internal referencing? >> 2. I think so. You'd just need a way to include internal targets in >> addition to the citation-references (keys); for illustration, >> something like [cite:#some-if]. > > I can't claim to have thought about this that much either, but something > like [cite:#some-fig] would seem to fit. > >> 3. If yes to both, should that hold back merger now? >> 3. No. > > I don't think this should hold up the merge either, but it's relevant in > the overall nature of the feature and perhaps could be shoehorned in > following the merge? I feel like this is one small quite simple case and > most of the thinking required has already been done. I'm not sure > though, I'd go with whatever Nic's thought are on this. At this point, I don't have enough understanding of the problem to have an opinion. IIUC, your example does not even mention citations. How should it be used, what should be the output in LaTeX, and in UTF-8 export? This is not clear to me. What can I say however is: if this feature implies to change, or extend, syntax, then it is /de facto/ a blocker for the merge, and needs to be sorted out. Regards, -- Nicolas Goaziou
Re: [wip-cite-new] Merging tomorrow?
Bruce D'Arcus writes: >> wip-cite-new deals with citing from bibliographies, but I don't think it >> deals with within-document referencing --- should it? > 1. Should it? > 1. Maybe. I feel like it would fit. With everything that's been done for citations, this feels like it may be a rather minor addition (or at least this is what I hope). > 2. Can it? Could the design be extended to include internal referencing? > 2. I think so. You'd just need a way to include internal targets in > addition to the citation-references (keys); for illustration, > something like [cite:#some-if]. I can't claim to have thought about this that much either, but something like [cite:#some-fig] would seem to fit. > 3. If yes to both, should that hold back merger now? > 3. No. I don't think this should hold up the merge either, but it's relevant in the overall nature of the feature and perhaps could be shoehorned in following the merge? I feel like this is one small quite simple case and most of the thinking required has already been done. I'm not sure though, I'd go with whatever Nic's thought are on this. Whichever way this diversion goes, I'm excited to see wip-cite-new merged! -- Timothy
Re: [wip-cite-new] Merging tomorrow?
Matt Price writes: > Really, I feel like there should be a parade. There will be one in the next edition of This Month in Org . -- Timothy
Re: [wip-cite-new] Merging tomorrow?
Matt Price wrote: > Really, I feel like there should be a parade. +1
Re: [wip-cite-new] Merging tomorrow?
Hi Nicolas,
first: thank you for all the work, especially for thinking of documentation for
end users. My biggest struggle with the current org (and emacs) documentation
is the lack of end-to-end examples. This makes it incredibly difficult to get
things working. It often is like „this is a big puzzle, some pieces are in
other boxes and we don’t provide a picture of how the final puzzle will look
like“. The documentation often makes sense once I get it running, though . But
this is to late.
This being the motivation, I would greatly appreciate the following:
——— snip ———-
Consider the following minimal viable example where an org file with one bibtex
file is rendered to pdf and html.
This is the BibTex file
#+begin_example bibtex
….
#+end_example
This is the org file
#+begin_example org
….
#+end_example
and this is the rendered html/Latex
- picture 1
- screenshot 2
This has been achieved with the following minimal configuration:
#+begin_example elisp
….
#+end_example
As you can see in line 42 the … etc, etc
If you would like to use two bibtex files you would need to change …
#+begin_example elisp
….
; change line 14 in the sample for one file like this:
(…)
…
#+end_example
——- snap ——-
That kind of documentation would have made many, many hours of frustrating
„search in google/github for a solution someone else has found“ and replace it
with „wow that was actually quite beginner friendly!“. Pictures also make it
much easier to visualize what is actually achieved.
Cheers
Jens
> On 8. Jul 2021, at 02:18, Nicolas Goaziou wrote:
>
> Hello,
>
> I think the "wip-cite-new" branch is in good shape now. As
> a consequence, I'd like to merge it tomorrow.
>
> It is documented, but the documentation is scattered across the various
> "oc" libraries, and some threads in the mailing list. I'll do a summary
> here, from a user point of view.
>
> --8<---cut here---start->8---
> Basically, in order to use it, you need to first set-up a bibliography,
> using one or more "bibliography" keywords. on such a keyword
> visits the related file. Out of the box, Org supports JSON-CSL and
> BibTeX (or biblatex) bibliographies.
>
> Then, citations can be inserted with the following syntax:
>
> [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
>
> Spaces are meaningful except those after the initial colon and before
> the closing bracket.
>
> Every part of the syntax is optional, except the brackets, "cite" and
> the colon. Also the citation must contain at least a key. So its minimal
> form is:
>
> [cite:@key]
>
> The "style" part is detailed below, in the part related to export.
>
> Org can insert or edit citations with (and delete them with
> ), follow them with , fontify them, and export
> them. These four actions (insert, follow, activate, and export) are
> called capabilities. Libraries responsible for these capabilities are
> called citation processors.
>
> You can select one citation processor for each capability, independently
> on the others, through the following variables:
>
> - org-cite-activate-processor
> - org-cite-export-processors
> - org-cite-follow-processor
> - org-cite-insert-processor
>
> Out of the box, Org provides the "basic" (in "oc-basic.el") processor
> for all of these tasks. It also boasts processors dedicated for export:
> "csl", "natbib" and "biblatex".
>
> During export, output for citations is controlled by their style, which
> is an Org label that the export processor may recognize and associate to
> a specific display, or fall-back to a default style (called "nil"). For
> example, most processors support "noauthor" and "text" styles.
>
> Some styles can accept a variant, with the syntax "style/variant".
> Again, it's up to the processor to associate it to a specific display.
> Common variants include "bare", "caps" or "full". They also accept
> short-hands, like "b", "c" and "f". Please refer to the export
> processors' libraries ("oc-basic.el", "oc-csl.el", …) for more information.
>
> It is possible to define a default style for a whole document (with
> "cite_export"), or for all documents (with `org-cite-export-processors').
>
> References are displayed with the "print_bibliography" keyword. It is
> possible to add parameters to its value, as some export processors could
> make use of them.
> --8<---cut here---end--->8---
>
> Please let me know if there are any objections to the merge.
>
> Regards,
> --
> Nicolas Goaziou
>
Re: [wip-cite-new] Merging tomorrow?
On Thu, Jul 08 2021, Bruce D'Arcus wrote: > On Wed, Jul 7, 2021 at 11:48 PM Timothy wrote: > >> wip-cite-new deals with citing from bibliographies, but I don't think it >> deals with within-document referencing --- should it? > > It doesn't now. > > I guess to break down the second question further: > > 1. Should it? One thing to keep in mind here: these are two different sets of functionality and a tool designed to handle one isn't necessarily right for handling the other. Org-cite provides four capabilities: insert, follow, activate and export. And while they may be very similar conceptually for a user, a provider would need to handle each of these very differently for citations and in-document references. And that's the point: while it makes sense for Ebib to provide insert and follow capabilities for citations, there is really no point in Ebib providing those for in-document references as well. It doesn't have the infrastructure for it, nor is Ebib the first (or even second or third) option that comes to mind when you think about inserting and following in-document references. I do think it makes sense if such a hypothetical org-new-ref has a very similar conceptual design to org-cite and a very similar user interface (e.g., the same keybindings), and perhaps a part of the code can be shared, it should be possible to register different provides for them. -- Joost Kremers Life has its moments
Re: [wip-cite-new] Merging tomorrow?
On Wed, Jul 7, 2021 at 11:48 PM Timothy wrote: > wip-cite-new deals with citing from bibliographies, but I don't think it > deals with within-document referencing --- should it? It doesn't now. I guess to break down the second question further: 1. Should it? 2. Can it? Could the design be extended to include internal referencing? 2. If yes to both, should that hold back merger now? I've not thought about this a lot, but my tentative view ... 1. Maybe. 2. I think so. You'd just need a way to include internal targets in addition to the citation-references (keys); for illustration, something like [cite:#some-if]. 3. No. I say no in part because while it's possible it's fairly straightforward to add this, it will take some thought, and there's probably details to sort out. And the code is ready, I think, based on the requirements that have been the focus the past year+. OTOH, perhaps this basic requirements question was raised before I joined the discussion, and it was already rejected? Either way, I don't think this should hold back merger now. It can be added later if it makes sense. Bruce
Re: [wip-cite-new] Merging tomorrow?
Nicolas Goaziou writes:
> I think the "wip-cite-new" branch is in good shape now. As
> a consequence, I'd like to merge it tomorrow.
This may be much too late to raise this (sorry), but I've got a query.
At the moment org-ref allows for:
+ citing from a bibliography
+ referencing elements within the document
wip-cite-new deals with citing from bibliographies, but I don't think it
deals with within-document referencing --- should it?
In case it helps, here's a small example of referencing elements with
org-ref:
#+begin_src org
,#+caption: Wow, look a me. label:some-f
[[file:some-file.png]]
Have you seen cref:some-f ?
#+end_src
Exported LaTeX:
#+begin_src LaTeX
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{some-file.png}
\caption{Wow, look a me. \label{some-f}}
\end{figure}
Have you seen \cref{some-f} ?
#+end_src
I know that we can get a label added with #+name, but I don't know that
there's an easy way to reference it without org-ref. I feel like ideally
this should be something Org provides.
--
Timothy
Re: [wip-cite-new] Merging tomorrow?
I cannot believe this is finally happening, and I am so stoked and excited
about it. I've been using ~wip-cite-new~ in my classes this week, and these
new tools are absolutely transformative.
Thank you so much for the immense amount of work you put into this. And
also to Bruce for championing it, and Andras and Denis and others for their
contributions. Really, I feel like there should be a parade.
Matt
On Wed, Jul 7, 2021 at 10:23 PM Thomas S. Dye wrote:
> Aloha Nicolas,
>
> Good news! I'm looking forward to using this facility.
>
> Thanks to all the contributors.
>
> All the best,
> Tom
>
> Nicolas Goaziou writes:
>
> > Hello,
> >
> > I think the "wip-cite-new" branch is in good shape now. As
> > a consequence, I'd like to merge it tomorrow.
> >
> > It is documented, but the documentation is scattered across the
> > various
> > "oc" libraries, and some threads in the mailing list. I'll do a
> > summary
> > here, from a user point of view.
> >
> > --8<---cut
> > here---start->8---
> > Basically, in order to use it, you need to first set-up a
> > bibliography,
> > using one or more "bibliography" keywords. on such a
> > keyword
> > visits the related file. Out of the box, Org supports JSON-CSL
> > and
> > BibTeX (or biblatex) bibliographies.
> >
> > Then, citations can be inserted with the following syntax:
> >
> > [cite/style:common prefix ;prefix @key suffix; ... ; common
> > suffix]
> >
> > Spaces are meaningful except those after the initial colon and
> > before
> > the closing bracket.
> >
> > Every part of the syntax is optional, except the brackets,
> > "cite" and
> > the colon. Also the citation must contain at least a key. So its
> > minimal
> > form is:
> >
> > [cite:@key]
> >
> > The "style" part is detailed below, in the part related to
> > export.
> >
> > Org can insert or edit citations with (and delete
> > them with
> > ), follow them with , fontify them, and
> > export
> > them. These four actions (insert, follow, activate, and export)
> > are
> > called capabilities. Libraries responsible for these
> > capabilities are
> > called citation processors.
> >
> > You can select one citation processor for each capability,
> > independently
> > on the others, through the following variables:
> >
> > - org-cite-activate-processor
> > - org-cite-export-processors
> > - org-cite-follow-processor
> > - org-cite-insert-processor
> >
> > Out of the box, Org provides the "basic" (in "oc-basic.el")
> > processor
> > for all of these tasks. It also boasts processors dedicated for
> > export:
> > "csl", "natbib" and "biblatex".
> >
> > During export, output for citations is controlled by their
> > style, which
> > is an Org label that the export processor may recognize and
> > associate to
> > a specific display, or fall-back to a default style (called
> > "nil"). For
> > example, most processors support "noauthor" and "text" styles.
> >
> > Some styles can accept a variant, with the syntax
> > "style/variant".
> > Again, it's up to the processor to associate it to a specific
> > display.
> > Common variants include "bare", "caps" or "full". They also
> > accept
> > short-hands, like "b", "c" and "f". Please refer to the export
> > processors' libraries ("oc-basic.el", "oc-csl.el", …) for more
> > information.
> >
> > It is possible to define a default style for a whole document
> > (with
> > "cite_export"), or for all documents (with
> > `org-cite-export-processors').
> >
> > References are displayed with the "print_bibliography" keyword.
> > It is
> > possible to add parameters to its value, as some export
> > processors could
> > make use of them.
> > --8<---cut
> > here---end--->8---
> >
> > Please let me know if there are any objections to the merge.
> >
> > Regards,
>
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>
>
Re: [wip-cite-new] Merging tomorrow?
Aloha Nicolas,
Good news! I'm looking forward to using this facility.
Thanks to all the contributors.
All the best,
Tom
Nicolas Goaziou writes:
Hello,
I think the "wip-cite-new" branch is in good shape now. As
a consequence, I'd like to merge it tomorrow.
It is documented, but the documentation is scattered across the
various
"oc" libraries, and some threads in the mailing list. I'll do a
summary
here, from a user point of view.
--8<---cut
here---start->8---
Basically, in order to use it, you need to first set-up a
bibliography,
using one or more "bibliography" keywords. on such a
keyword
visits the related file. Out of the box, Org supports JSON-CSL
and
BibTeX (or biblatex) bibliographies.
Then, citations can be inserted with the following syntax:
[cite/style:common prefix ;prefix @key suffix; ... ; common
suffix]
Spaces are meaningful except those after the initial colon and
before
the closing bracket.
Every part of the syntax is optional, except the brackets,
"cite" and
the colon. Also the citation must contain at least a key. So its
minimal
form is:
[cite:@key]
The "style" part is detailed below, in the part related to
export.
Org can insert or edit citations with (and delete
them with
), follow them with , fontify them, and
export
them. These four actions (insert, follow, activate, and export)
are
called capabilities. Libraries responsible for these
capabilities are
called citation processors.
You can select one citation processor for each capability,
independently
on the others, through the following variables:
- org-cite-activate-processor
- org-cite-export-processors
- org-cite-follow-processor
- org-cite-insert-processor
Out of the box, Org provides the "basic" (in "oc-basic.el")
processor
for all of these tasks. It also boasts processors dedicated for
export:
"csl", "natbib" and "biblatex".
During export, output for citations is controlled by their
style, which
is an Org label that the export processor may recognize and
associate to
a specific display, or fall-back to a default style (called
"nil"). For
example, most processors support "noauthor" and "text" styles.
Some styles can accept a variant, with the syntax
"style/variant".
Again, it's up to the processor to associate it to a specific
display.
Common variants include "bare", "caps" or "full". They also
accept
short-hands, like "b", "c" and "f". Please refer to the export
processors' libraries ("oc-basic.el", "oc-csl.el", …) for more
information.
It is possible to define a default style for a whole document
(with
"cite_export"), or for all documents (with
`org-cite-export-processors').
References are displayed with the "print_bibliography" keyword.
It is
possible to add parameters to its value, as some export
processors could
make use of them.
--8<---cut
here---end--->8---
Please let me know if there are any objections to the merge.
Regards,
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: [wip-cite-new] Merging tomorrow?
On 8 July 2021, Nicolas Goaziou wrote: Please let me know if there are any objections to the merge. I do not object---I am eager to try it! I haven't experimented with the work as it was being done, but I was very impressed with and grateful for all the work that everyone did on this. I'm a librarian, so I know how ridiculous and bizarre citation formats are, but I still learned a lot about how complex it is to write code to handle them. My thanks to everyone involved for doing such great work to add a wonderful new feature to Org. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator.
[wip-cite-new] Merging tomorrow?
Hello,
I think the "wip-cite-new" branch is in good shape now. As
a consequence, I'd like to merge it tomorrow.
It is documented, but the documentation is scattered across the various
"oc" libraries, and some threads in the mailing list. I'll do a summary
here, from a user point of view.
--8<---cut here---start->8---
Basically, in order to use it, you need to first set-up a bibliography,
using one or more "bibliography" keywords. on such a keyword
visits the related file. Out of the box, Org supports JSON-CSL and
BibTeX (or biblatex) bibliographies.
Then, citations can be inserted with the following syntax:
[cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
Spaces are meaningful except those after the initial colon and before
the closing bracket.
Every part of the syntax is optional, except the brackets, "cite" and
the colon. Also the citation must contain at least a key. So its minimal
form is:
[cite:@key]
The "style" part is detailed below, in the part related to export.
Org can insert or edit citations with (and delete them with
), follow them with , fontify them, and export
them. These four actions (insert, follow, activate, and export) are
called capabilities. Libraries responsible for these capabilities are
called citation processors.
You can select one citation processor for each capability, independently
on the others, through the following variables:
- org-cite-activate-processor
- org-cite-export-processors
- org-cite-follow-processor
- org-cite-insert-processor
Out of the box, Org provides the "basic" (in "oc-basic.el") processor
for all of these tasks. It also boasts processors dedicated for export:
"csl", "natbib" and "biblatex".
During export, output for citations is controlled by their style, which
is an Org label that the export processor may recognize and associate to
a specific display, or fall-back to a default style (called "nil"). For
example, most processors support "noauthor" and "text" styles.
Some styles can accept a variant, with the syntax "style/variant".
Again, it's up to the processor to associate it to a specific display.
Common variants include "bare", "caps" or "full". They also accept
short-hands, like "b", "c" and "f". Please refer to the export
processors' libraries ("oc-basic.el", "oc-csl.el", …) for more information.
It is possible to define a default style for a whole document (with
"cite_export"), or for all documents (with `org-cite-export-processors').
References are displayed with the "print_bibliography" keyword. It is
possible to add parameters to its value, as some export processors could
make use of them.
--8<---cut here---end--->8---
Please let me know if there are any objections to the merge.
Regards,
--
Nicolas Goaziou
