Re: [O] org-cite and org-citeproc

[Richard Lawrence]

Rasmus  writes:

> Richard: do your FSF papers in order.  Or do you plan to get them in
> order?

I haven't done them yet (never had a reason to!) but I have no problems
with it and I'll get started on it.  

Best,
Richard

Re: [O] Standard agenda views don't show file name after update (replaced by "???:")

[John Hendy]

Confirmed to be working great again. Thanks for the speedy response (as always)!

John

On Wed, Apr 1, 2015 at 3:44 PM, Nicolas Goaziou  wrote:
> Hello,
>
> John Hendy  writes:
>
>> I just pulled for the first time in a while and found I get question
>> marks in my agenda view instead of the former use of the file name
>> (see attached). I did a bunch of git pulling/make cleaning/making, and
>> traced it to this commit from Nicholas:
>> - 80bccca4e249cbb5812963863ccffbdcf4b25edd
>>
>> Commit c1a744659d2b44c067ecb195b3e5d51e837bddd is working properly.
>>
>> I verified with a minimal config containing only:
>>
>> (add-to-list 'load-path "~/.elisp/org.git/lisp/")
>>
>> My test file contained:
>>
>> * TODO something
>>
>> * TODO something else
>>
>> Process:
>> - emacs -Q
>> - M-x load-file [RET] /path/to/min-config
>> - M-x org-agenda-file-to-front
>> - M-x org-agenda [RET] t
>
> Fixed in 22bf1b8ae3c2842945b9b9d9ab2ca203eae17946. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Best practices for dual HTML/LaTeX export for scientific papers

[Charles C. Berry]

On Thu, 2 Apr 2015, Rasmus wrote:


Hi,

David Dynerman  writes:



[snip]



2) Figures containing multiple side-by-side figures with subcaptions 
(e.g. in LaTeX I would use minipage + subcaption)


For LaTeX you can find solution on this list.  I would not know how to do
it in "plain" HTML.  That would be the first step to a solution.




You can get part way just by using a table.

#+NAME: as-org
#+BEGIN_SRC org
#+ATTR_LATEX: :environment figure
| [[file:./testa.png]] | [[file:./testb.png]]  |
#+END_SRC

#+BEGIN_SRC emacs-lisp :var y=as-org() :wrap latex
(org-export-string-as y 'latex t)
#+END_SRC

#+BEGIN_SRC emacs-lisp :var y=as-org() :wrap html
(org-export-string-as y 'html t)
#+END_SRC


With ob-org.el loaded, the two elisp blocks will produce tables of images 
in the latex and html backends.


Some further work is needed to adjust the `width=...' of the latex result
and to put captions in the right places in both latex and html.

Using the babel blocks makes it easy to see what might be needed.

In the end, I expect a filter would be used rather than babel blocks.

HTH,

Chuck

Re: [O] Bug: Proposed new version of ob-C.el [8.3beta (release_8.3beta-944-g830cf3 @ /Users/snapp/.emacs.d/vendor/org/)]

[Thierry Banel]

Le 01/04/2015 00:14, Nick Dokos a écrit :
>
> I was thinking of an ob-C.el customizable variable that is set by
> default to some useful list of includes, not file-settable things.
> But I'm probably the last person you should ask about what is useful
> here. Real users should speak up.
>
> I think augmentation might be nice, but if people are willing to live
> with replacement, I'm not going to argue. And if augmentation carries
> the day, there always is the vexing question of what to do when you
> really *want* replacement, not augmentation.
>

The situation is as follow.
Values for :includes are searched in several locations, in this order:
  1) #+BEGIN_SRC C++ :includes 
  2) org-babel-default-header-args:C++ '(:includes  "")
  3) org-babel-default-header-args '(:includes  "")
The search stops as soon as a value is found.
Thus we have a "replacement" logic rather than an "augmentation" one.

This works for :includes, but also for :defines, and every possible
parameter.  It also works for C, D, elisp, and any language.  It is a
generic feature of Babel.  To play with it, type C-c C-v I in the source
block.

The variables are declared in this way:
  (defvar org-babel-default-header-args:fortran)
Maybe they could be changed to:
  (defcustom org-babel-default-header-args:fortran)
to enable customization through Emacs customization facility...

Changing from a "replacement" behavior to an "augmentation" one involves
changing it for all languages at the same time, because it is
implemented in the core of Babel.  Moreover, it would require to know
which parameters hold single values, and which ones hold lists. 
Definitely more than a quick and small change.

[O] Emacs-Orgmode Archive search fails

[Charles Millar]

It has been a while since I searched the mailing list archives. Did I 
miss an announcement or is the search engine broken?


For the past few days, any search request in the mailing list archives 
either yields no result or just one and the same result - "Citations, 
continued, etc." /archive/html/emacs-orgmode/2015-02/msg00028.html 
 
(7,961 bytes)


This occurs on both Debian and Windows 7 machine.

Charlie Millar

Re: [O] org-cite and org-citeproc

[Andreas Leha]

Hi,

Richard Lawrence  writes:
> Hi Eric and all,
>
> Eric S Fraga  writes:
>
>> On Wednesday,  1 Apr 2015 at 08:49, Andreas Leha wrote:
>>
>> [...]
>>
>>> I am a happy biblatex user for all my 'own' documents.  But (as was
>>> mentioned previously) scientific journals that accept latex submissions
>>> will require bibtex and won't support biblatex.  So, I'd say that one of
>>> the other methods (preferably bibtex) is still necessary.
>>
>> Ahhh, yes, I'd forgotten that journals expect bibtex.  This is a key
>> requirement for me as well therefore.
>
> Can someone suggest how a parenthetical citation with common prefix and
> suffix data, like
>
>   [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
>   and references therein.] 
>
> should map to plain BibTeX?  Maybe there is no general answer to this
> question, but what would a reasonable default be?  Maybe this?
>
>   (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
>   and references therein.)
>
> That is, just place the prefix and suffix data in the surrounding text,
> inserting commas after the part for each individual work, and wrapping
> the whole thing in parentheses?
>

To me that seems a reasonable thing to do.  At least I would write it
probably in such a way.

Depending on the citation style ("author, year") I might add a comma
after the citation, so that it becomes

  (For more on this topic, see: Max Mustermann, 2015, for a review, 
   The Internet Consortium, 2014, and references therein.)

compared to

  (For more on this topic, see: Max Mustermann, 2015 for a review, 
   The Internet Consortium, 2014 and references therein.)

But:
- I am no native English speaker and comma placement in English
  is very unclear to me
- my citation requirements are quite low, I guess...

Best,
Andreas

Re: [O] org-cite and org-citeproc

[Rasmus]

Hi,

Aaron Ecay  writes:

> I went round and round with myself about this, and concluded that we
> ought to keep on working on the org-citeproc approach for now (drop
> citeproc-java).  But I do think someone eventually ought to reimplement
> org-citeproc based on citeproc-js, to yield something that can be
> distributed via npm.  This will be less fool-proof than java, but better
> than the Haskell experience for many users (such as Rasmus and me – far
> from non-technical people!).  You mention zotero as a third option –
> it’s possible, but I think we’d be better served by a tool that focuses
> solely on processing and is not so closely tied with database
> management.

I mostly agree.

IMO a non-binary Haskell solution is a non-starter for an "official"
solution.  A binary version is fine: e.g. I'm more or less happy with
git-annex.

I'd prefer java over node-js, but I'm less hostile towards npm.

Could there be an elisp wrapper around citeproc-js?  Likely, org devs
would have an easier time maintaining such a beast.  

> The first is whether the processor generates the in-text citations (you)
> or whether it’s done in elisp (me).  It’s not obvious which is superior.
> The real test will come when more diverse citation types are implemented
> (e.g. full citations in footnotes or numbers which reference a numbered
> bibliography at the end of the document).

IMO externalization is the top priority.  After that I think elisp is
superior as org-devs presumably would have an easier time maintaining
this.


>> This complicates things enough that probably custom citation modes
>> [in Latex – AE] should be defined as Lisp functions, rather than via
>> format strings...what do you think?
>
> I’d rather avoid it, since I think org->latex is going to be an important
> usecase for many people.  I see us eventually supporting two flavors of
> latex output.  The first should aim to generate a full set of biblatex
> commands but with little user customizability.  The second will rely on
> just 2 citation commands (paren and non-paren), plus some elisp routines
> for combining them into multicites etc.  These two cite commands then can
> be customized by the user.

E.g. Natbib has primitives such as \citeauthor and \citeyear so
arbitrarily complex biblatex citations can always be replicated.



>> Also useful.  This might take a while for me to figure out, as Pandoc
>> does not seem to generate this markup when formatting a
>> bibliography...maybe I'll see if they are willing to work on this
>> upstream.
>
> I think we should not rely on pandoc to fix this for us.  It makes it
> harder to move away from Haskell if (when) we want to.

+1

> I used up all the time I had today to understanding the code and
> surrounding conceptual issues.  However, I will try to integrate your
> changes with my branch sometime in the next few days-week.

Richard: do your FSF papers in order.  Or do you plan to get them in
order?

—Rasmus

-- 
Send from my Emacs

Re: [O] org-cite and org-citeproc

[Richard Lawrence]

Hi Aaron,

Thanks for your comments, and for looking over my code!

Aaron Ecay  writes:

> I’ve been (barely) following this discussion, but have been too busy to
> do any actual coding.  I sat down today to try to integrate Richard’s
> branch with my work, but didn’t get very far.  I think it would be a
> waste of effort to try to support more than one citation processor
> (citeproc-java vs. org-citeproc).

In the long run, I agree, though I still think it might be good in the
short term to see how a few different tools behave.

> I went round and round with myself about this, and concluded that we
> ought to keep on working on the org-citeproc approach for now (drop
> citeproc-java).  

(I take that as a compliment -- thanks!  I'm curious as to what persuaded
you.)

> But I do think someone eventually ought to reimplement org-citeproc
> based on citeproc-js, to yield something that can be distributed via
> npm.  This will be less fool-proof than java, but better than the
> Haskell experience for many users (such as Rasmus and me – far from
> non-technical people!).

That is fine with me, as I think citeproc-js is the canonical
implementation, and probably the best supported.  I am not the person to
do this, though, as I don't really know JavaScript, and personally I
have found it rather frustrating to work with whenever I have had to do
so.

(I am a little puzzled, though, as to why you and Rasmus find the
Haskell experience unpalatable.  On my machine, I installed the Haskell
Platform, and after that, building and installing pandoc,
pandoc-citeproc, and other programs via cabal Just Works.  Has that not
been your experience?  Why would instructions like "First install Node.js,
then do: $ npm install org-citeproc" be better than "First install the
Haskell platform, then do: $ cabal install org-citeproc"?) 

> You mention zotero as a third option – it’s possible, but I think we’d
> be better served by a tool that focuses solely on processing and is
> not so closely tied with database management.

Yes, I agree, at least for those of us who don't use a citation manager.
On the other hand, other people already have Zotero, but would find it
difficult to install and configure a command-line tool and supporting
platform.

If there were a common API so that most of org-cite could operate
independently of external tools, but call out to whichever tool was
installed at critical moments, I think that would be beneficial from a
user's perspective.  (That was part of my motivation for representing
citations to org-citeproc as citeproc-js-compatible JSON.)  I know that
would be more work, but it shouldn't lead to too much duplicated effort
if we are careful to separate the tool-independent code from the
tool-dependent code, and to minimize the latter.  It would also make it
easier to support new and better tools in the future as they become
available.

> There are a couple of other differences in our approaches.
>
> The first is whether the processor generates the in-text citations (you)
> or whether it’s done in elisp (me).  It’s not obvious which is superior.
> The real test will come when more diverse citation types are implemented
> (e.g. full citations in footnotes or numbers which reference a numbered
> bibliography at the end of the document).
>
> The second is whether the processor generates markup in the target
> language directly (you) or whether the processor’s output is converted
> to org markup, then passed through org’s exporters (me).  I think my
> approach here is preferable, since it generalizes to every backend.  Do
> you think something like this could work for org-citeproc?  It would
> probably require some additional special code in ox-odt.  (But we might
> need that in any case, see below.)

Yes, I think that could work, and shouldn't be too hard to achieve, as
Pandoc already has an Org writer.  And I agree it is probably preferable
to go this way.  I realized this when I tested org-citeproc with a CSL
file for a note-based style; things start to get complicated when you
have to parse the output format to look for e.g. a footnote reference
and definition.

> It would be good from an intelligibility/maintainability perspective if
> you could use the json.el library rather than generating json strings by
> hand.  This is part of the emacs core since version 23.something, so
> compatibility should not be a big issue.

Ah, ok, I didn't know about json.el.  Yes, I agree.

> You wrote (mixing replies to various emails in this thread):
>
>> This complicates things enough that probably custom citation modes
>> [in Latex – AE] should be defined as Lisp functions, rather than via
>> format strings...what do you think?
>
> I’d rather avoid it, since I think org->latex is going to be an important
> usecase for many people.  I see us eventually supporting two flavors of
> latex output.  The first should aim to generate a full set of biblatex
> commands but with little user customizability.  The second will r

Re: [O] org-cite and org-citeproc

[Thomas S. Dye]

Hi Richard,

Richard Lawrence  writes:

> Hi Tom and all,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>>> OK, I see, that makes things clearer.  Would it make sense to have two
>>> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
>>> style can vary independently when exporting to LaTeX vs. non-LaTeX?  I'm
>>> thinking it will be tricky to come up with a single set of values for a
>>> CITATION_STYLE keyword that can be correctly mapped to both kinds of
>>> backend.  Or maybe CITATION_STYLE should have "sub"-keywords, like
>>>
>>> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl
>>
>> Won't the backends sort this out without the additional mapping?
>
> Surely they could, but I guess I'm unclear on how that should happen.
>
> Org could keep a variable mapping citation styles to default values for
> the respective backends, like:
>
> (defcustom org-cite-citation-styles
>   '(("author-year" (biblatex-pkg-args 
> "citestyle=authoryear,bibstyle=authoryear")
>(csl-file "/path/to/chicago-author-date.csl"))
>...))
>
> so in a document, you could just write
>
> #+CITATION_STYLE: author-year
>
> or similar.  Is this what you have in mind?
>
> That seems like a good way to provide reasonable defaults using a
> high-level label.  But I think using a high-level label like this will
> underdetermine the actual style to use (on both sides, I assume); and
> the problem is that if we make the labels more fine-grained, there's no
> longer any guarantee that, for a given style label, a suitable style
> file will be available on both LaTeX and non-LaTeX backends.
>
> There obviously needs to be some mechanism so authors can specify their
> citation style quite precisely for the backends they are interested in.
> (Maybe just customizing this variable would do the trick.)  But what
> should the fallback mechanism look like when a particular style does not
> specify the required information for a given export backend?  E.g., if
> CITATION_STYLE is X and we're exporting to HTML, but the entry in
> org-cite-citation-styles does not specify a CSL file for style X?  Would
> it be enough to have a single 'default clause or similar in
> org-cite-citation-styles to use in that kind of case?

I was thinking the author would change CITATION_STYLE to fit the export,
but I like your idea of setting up a universal configuration.

As for a fallback mechanism, I like your idea of a user-configurable
default.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] org-cite and org-citeproc

[Richard Lawrence]

Hi Tom and all,

t...@tsdye.com (Thomas S. Dye) writes:

>> OK, I see, that makes things clearer.  Would it make sense to have two
>> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
>> style can vary independently when exporting to LaTeX vs. non-LaTeX?  I'm
>> thinking it will be tricky to come up with a single set of values for a
>> CITATION_STYLE keyword that can be correctly mapped to both kinds of
>> backend.  Or maybe CITATION_STYLE should have "sub"-keywords, like
>>
>> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl
>
> Won't the backends sort this out without the additional mapping?

Surely they could, but I guess I'm unclear on how that should happen.

Org could keep a variable mapping citation styles to default values for
the respective backends, like:

(defcustom org-cite-citation-styles
  '(("author-year" (biblatex-pkg-args 
"citestyle=authoryear,bibstyle=authoryear")
   (csl-file "/path/to/chicago-author-date.csl"))
   ...))

so in a document, you could just write

#+CITATION_STYLE: author-year

or similar.  Is this what you have in mind?

That seems like a good way to provide reasonable defaults using a
high-level label.  But I think using a high-level label like this will
underdetermine the actual style to use (on both sides, I assume); and
the problem is that if we make the labels more fine-grained, there's no
longer any guarantee that, for a given style label, a suitable style
file will be available on both LaTeX and non-LaTeX backends.

There obviously needs to be some mechanism so authors can specify their
citation style quite precisely for the backends they are interested in.
(Maybe just customizing this variable would do the trick.)  But what
should the fallback mechanism look like when a particular style does not
specify the required information for a given export backend?  E.g., if
CITATION_STYLE is X and we're exporting to HTML, but the entry in
org-cite-citation-styles does not specify a CSL file for style X?  Would
it be enough to have a single 'default clause or similar in
org-cite-citation-styles to use in that kind of case?

Best,
Richard

Re: [O] org-cite and org-citeproc

[Aaron Ecay]

Hi Richard, hi all,

First of all, thanks very much for your work!

I’ve been (barely) following this discussion, but have been too busy to
do any actual coding.  I sat down today to try to integrate Richard’s
branch with my work, but didn’t get very far.  I think it would be a
waste of effort to try to support more than one citation processor
(citeproc-java vs. org-citeproc).

I went round and round with myself about this, and concluded that we
ought to keep on working on the org-citeproc approach for now (drop
citeproc-java).  But I do think someone eventually ought to reimplement
org-citeproc based on citeproc-js, to yield something that can be
distributed via npm.  This will be less fool-proof than java, but better
than the Haskell experience for many users (such as Rasmus and me – far
from non-technical people!).  You mention zotero as a third option –
it’s possible, but I think we’d be better served by a tool that focuses
solely on processing and is not so closely tied with database
management.

There are a couple of other differences in our approaches.

The first is whether the processor generates the in-text citations (you)
or whether it’s done in elisp (me).  It’s not obvious which is superior.
The real test will come when more diverse citation types are implemented
(e.g. full citations in footnotes or numbers which reference a numbered
bibliography at the end of the document).

The second is whether the processor generates markup in the target
language directly (you) or whether the processor’s output is converted
to org markup, then passed through org’s exporters (me).  I think my
approach here is preferable, since it generalizes to every backend.  Do
you think something like this could work for org-citeproc?  It would
probably require some additional special code in ox-odt.  (But we might
need that in any case, see below.)

It would be good from an intelligibility/maintainability perspective if
you could use the json.el library rather than generating json strings by
hand.  This is part of the emacs core since version 23.something, so
compatibility should not be a big issue.

You wrote (mixing replies to various emails in this thread):

> This complicates things enough that probably custom citation modes
> [in Latex – AE] should be defined as Lisp functions, rather than via
> format strings...what do you think?

I’d rather avoid it, since I think org->latex is going to be an important
usecase for many people.  I see us eventually supporting two flavors of
latex output.  The first should aim to generate a full set of biblatex
commands but with little user customizability.  The second will rely on
just 2 citation commands (paren and non-paren), plus some elisp routines
for combining them into multicites etc.  These two cite commands then can
be customized by the user.

If people need more flexibility but cannot use biblatex, they can
always hack up a custom exporter for themselves.  But I think we ought
to support relatively simple needs with simple configuration settings.

> OK, I see, that makes things clearer.  Would it make sense to have two
> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
> style can vary independently when exporting to LaTeX vs. non-LaTeX?  

Yes.

> I'm thinking it will be tricky to come up with a single set of values
> for a CITATION_STYLE keyword that can be correctly mapped to both
> kinds of backend.  

I agree.

> Or maybe CITATION_STYLE should have "sub"-keywords, like
> 
> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl

This is equivalent (up to bikeshedding) to separate keywords.  I’d like
the bikeshed painted with separate keywords, though, because that leaves
room for passing additional options to biblatex (to be added to the
\usepackage and/or \printbibliography commands).

> Can someone suggest how a parenthetical citation with common prefix and
> suffix data, like
> 
>   [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
>   and references therein.] 
> 
> should map to plain BibTeX?  Maybe there is no general answer to this
> question, but what would a reasonable default be?  Maybe this?
> 
>   (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
>   and references therein.)
> 
> That is, just place the prefix and suffix data in the surrounding text,
> inserting commas after the part for each individual work, and wrapping
> the whole thing in parentheses?

I agree.  (This is like the second flavor of latex support I described
above.)

> Also useful.  This might take a while for me to figure out, as Pandoc
> does not seem to generate this markup when formatting a
> bibliography...maybe I'll see if they are willing to work on this
> upstream.

I think we should not rely on pandoc to fix this for us.  It makes it
harder to move away from Haskell if (when) we want to.

I used up all the time I had today to understanding the code and
surrounding conceptual issues.  However, I will try to integ

Re: [O] Best practices for dual HTML/LaTeX export for scientific papers

[Rasmus]

Hi,

David Dynerman  writes:

> 1) Citations to an external bibliography

I use a home-brewed solution.  If your requirements are modest there's
also ox-bibtex.el in addition to John's package (which I haven't tried).

In the future there may be a "official" solution.

> 2) Figures containing multiple side-by-side figures with subcaptions (e.g. in 
> LaTeX I would use minipage + subcaption)

For LaTeX you can find solution on this list.  I would not know how to do
it in "plain" HTML.  That would be the first step to a solution.

> 3) In-document links (i.e., cross references) to figures (e.g., “See Figure 
> 1”)

Can't you just do:

 #+NAME: fig
 #+CAPTION: caption
 [[file:fig.png]]

 See figure [[fig]]

> 4) LaTeX and HTML export

ox stands for org export.  A number of backends including LaTeX and html
are supported.  It's documented in the manual.

> Is it an issue of adding some functionality to the HTML exporter?

Patches are welcome, but you should aim to target as all relevant
backends.  For your own solution you can use filters or you can ox-publish
and change the functions that you desire to change.

Hope it helps,
Rasmus

-- 
Send from my Emacs

Re: [O] Best practices for dual HTML/LaTeX export for scientific papers

[John Kitchin]

#1 org-ref does an ok job with this. It isn't as good at html output as
 for latex output (because latex has a dedicated citation processor via
 bib(la)tex, and org-ref has a hackery for generating mostly ok entries
 from the bibtex file, for the common types I have used.). For example,
 you often need to escape things like % and & in bibtex, and there is
 limited support for removing those in org-ref. Also, org-ref currently
 does not support latex in the bibtex entries for html output. There is
 potential for this by replacing fragments with images, but I probably
 won't look into that until the summer. The output style is
 user-customizable, but currently somewhat limited. I may look into
 improving this over the summer to make it more flexible.

Cannot comment on #2. I solve this by manually by putting both figures
in a single image file, and using a single caption with a) and b) in the
caption text.

#3 I just pushed a small enhancement to org-ref that makes the ref links
point to a #id in the html document. this works for figures at least. It
will take some post processing to change the link from the label to a
number, and maybe a custom exporter to do that. A temporary solution is to
label your figures with numbers, e.g. #+LABEL: fig:1. It isn't pretty,
but it would be functional.

David Dynerman writes:

> Hi all,
>
> I’m currently trying to use org mode to write a scientific paper. Here is my 
> wishlist:
>
> 1) Citations to an external bibliography
> 2) Figures containing multiple side-by-side figures with subcaptions (e.g. in 
> LaTeX I would use minipage + subcaption)
> 3) In-document links (i.e., cross references) to figures (e.g., “See Figure 
> 1”)
> 4) LaTeX and HTML export
>
> This seems like a modest set of requirements, but I’ve had trouble getting it 
> going.
>
> For #1, I’m currently using John Kitchin’s org-ref package. This is nice - it 
> gives me an HTML bibliography, but it has it’s own link syntax for 
> in-document links to figures that doesn’t export to HTML. Thus I have to use 
> org-ref style links for citations, but regular org-style links for figure 
> cross references.
>
> I haven’t figured out how to do #2. Is this currently possible? Is it an 
> issue of adding some functionality to the HTML exporter?
>
> For #3, I’m currently using #+LABEL: fig:foo, followed by [[fig:foo]]. Is 
> this the suggested way of doing it?
>
> The hard part seems #4: org-ref gives a workable HTML bibliography, but I run 
> into some other issues listed above.
>
> Can anyone suggest some “Best practices” for the above? I’d be willing to 
> collect these into a list, which I think would be really helpful for new 
> users. I’d also be willing to look into adding this functionality, if someone 
> could suggest a good way for it to fit into the codebase/framework.
>
> Thank you,
> David

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] org-cite and org-citeproc

[Richard Lawrence]

Hi Rasmus,

Thanks, this is helpful.  I will try to fix these things soon.

Rasmus  writes:
>
>> Hmm.  But the citations are all just represented as 
>> nodes...surely that doesn't have to be defined elsewhere?
>
> You are right.  Also, oolatex inserts citations as plain text as well.  As
> I recall, it can be done "semantically" and section 6.3 of the odt
> standard suggest that this may be true, but it's not immediately obvious
> how to do it.
>
>> I am now guessing that the problem is that you can't have one 
>> inside another.  Each paragraph is wrapped in a , but so are the
>> citations within it...maybe that is not correct and so LibreOffice
>> doesn't like it.
>
> I don't think  can be nested cf.
>
> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415138_253892949

OK, good to know.  Looks like  or  might
be the way to go. 

>>> Also, the bibliography is not "correct" in the sense that if it was setup
>>> in the right semantic way, it would be gray in LO, like the TOC.
>>
>> Do you know what other markup is required in this case?  It looks like
>> maybe the TOC is gray because it is marked with a "text:protected"
>> attribute, or maybe because it has an associated "OrgIndexSection"
>> style?
>
> It has to be formatted as a bibliography.
>
> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_bibliography
>

Also useful.  This might take a while for me to figure out, as Pandoc
does not seem to generate this markup when formatting a
bibliography...maybe I'll see if they are willing to work on this
upstream.

Best,
Richard

Re: [O] org-cite and org-citeproc

[Richard Lawrence]

Hi Eric and all,

Eric S Fraga  writes:

> On Wednesday,  1 Apr 2015 at 08:49, Andreas Leha wrote:
>
> [...]
>
>> I am a happy biblatex user for all my 'own' documents.  But (as was
>> mentioned previously) scientific journals that accept latex submissions
>> will require bibtex and won't support biblatex.  So, I'd say that one of
>> the other methods (preferably bibtex) is still necessary.
>
> Ahhh, yes, I'd forgotten that journals expect bibtex.  This is a key
> requirement for me as well therefore.

Can someone suggest how a parenthetical citation with common prefix and
suffix data, like

  [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
  and references therein.] 

should map to plain BibTeX?  Maybe there is no general answer to this
question, but what would a reasonable default be?  Maybe this?

  (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
  and references therein.)

That is, just place the prefix and suffix data in the surrounding text,
inserting commas after the part for each individual work, and wrapping
the whole thing in parentheses?

Thanks!
 
Best,
Richard

Re: [O] Best practices for dual HTML/LaTeX export for scientific papers

[Eric S Fraga]

On Thursday,  2 Apr 2015 at 09:30, David Dynerman wrote:
> Hi all,
>
> I’m currently trying to use org mode to write a scientific paper. Here is my 
> wishlist:

I only ever target LaTeX so cannot help with the HTML end of things.

> 1) Citations to an external bibliography

John Kitchin's org-ref package is probably the way to go.  I don't use
it but use simply [[cite:blah-et-al]] which exports, in LaTeX, to
\cite{blah-et-al} and I make sure that my org-latex-pdf-process runs
bibtex on the resulting LaTeX.

> 2) Figures containing multiple side-by-side figures with subcaptions (e.g. in 
> LaTeX I would use minipage + subcaption)

Not sure how to do this.

> 3) In-document links (i.e., cross references) to figures (e.g., “See Figure 
> 1”)

What you currently do is what I do, labelling with
 #+label: fig-label
and referring via [[fig-label]]).

> 4) LaTeX and HTML export

I don't bother with the latter although you may be able to use one of
the LaTeX to HTML converters out there to good effect (pandoc, htlatex)?

The recent developments on citation syntax for org may help resolve some
of the issues with multiple export targets for scientific papers,
however.  Stay tuned!

HTH,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84

[O] Best practices for dual HTML/LaTeX export for scientific papers

[David Dynerman]

Hi all,

I’m currently trying to use org mode to write a scientific paper. Here is my 
wishlist:

1) Citations to an external bibliography
2) Figures containing multiple side-by-side figures with subcaptions (e.g. in 
LaTeX I would use minipage + subcaption)
3) In-document links (i.e., cross references) to figures (e.g., “See Figure 1”)
4) LaTeX and HTML export

This seems like a modest set of requirements, but I’ve had trouble getting it 
going.

For #1, I’m currently using John Kitchin’s org-ref package. This is nice - it 
gives me an HTML bibliography, but it has it’s own link syntax for in-document 
links to figures that doesn’t export to HTML. Thus I have to use org-ref style 
links for citations, but regular org-style links for figure cross references.

I haven’t figured out how to do #2. Is this currently possible? Is it an issue 
of adding some functionality to the HTML exporter?

For #3, I’m currently using #+LABEL: fig:foo, followed by [[fig:foo]]. Is this 
the suggested way of doing it?

The hard part seems #4: org-ref gives a workable HTML bibliography, but I run 
into some other issues listed above.

Can anyone suggest some “Best practices” for the above? I’d be willing to 
collect these into a list, which I think would be really helpful for new users. 
I’d also be willing to look into adding this functionality, if someone could 
suggest a good way for it to fit into the codebase/framework.

Thank you,
David



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] org-cite and org-citeproc

[Eric S Fraga]

On Wednesday,  1 Apr 2015 at 08:49, Andreas Leha wrote:

[...]

> I am a happy biblatex user for all my 'own' documents.  But (as was
> mentioned previously) scientific journals that accept latex submissions
> will require bibtex and won't support biblatex.  So, I'd say that one of
> the other methods (preferably bibtex) is still necessary.

Ahhh, yes, I'd forgotten that journals expect bibtex.  This is a key
requirement for me as well therefore.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84

Re: [O] org-mode to latex, again!

[Stefan Nobis]

Marcin Borkowski  writes:

> As I wrote - yes, provided you update the filename database
> (e.g. launching mktexlsr from the command line). (Because of speed, TeX
> does not search the directory tree each time it looks for a package or
> something, but uses a database in a familiar, "ls -R" format.)

This is true, but with one exception: the user texmf tree. So
everything below ~/texmf (or ~/Library/texmf on Mac OS X) should work
without running mktexlsr (on a default TeXLive installation).

-- 
Until the next mail...,
Stefan.

Re: [O] Define org-capture-templates with variables via customize

[Nicolas Goaziou]

Xavier Maillard  writes:

> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> Nick Dokos  writes:
>>
>>> Trying to just read Xavier's email message in Gnus, I get the following
>>> backtrace (with unprintable characters replaced by periods) - to me, this
>>> looks like a bug somewhere, but not sure where:
>>>
>>> Debugger entered--Lisp error: (error "Before first headline at position 114 
>>> in buffer *fontification*<2>")
>>
>> Fixed in c1a744659d2b44c067ecb195b3e5d51e837bddd1. Thank you.
>
> Glad you fixed that bug. Now that I am visible, is there any way to achieve 
> what I need
> ? :D

I don't think so. You are trying to mix two different concepts.
Customize is self-contained and generally helps users to avoid Elisp.
OTOH when you're defining a new variable, you embrace Elisp.

Regards,

Re: [O] [BUG] S-tab shows sub-headlines of archived headlines when org-inlinetask is loaded

[Francesco Pizzolante]

Hi Nicolas,

> Fixed in 03e81f0d240271d072fd155d41e59b6b353abaa9. Thank you.

I just tested it and it works great.

Thanks a lot!

Regards,
 Francesco