knitr vs knit2html rstudio button

[rmflight]

Hi Carl,

I have been looking at the problem of getting differences between using the rstudio knit2html button and calling knitr directly, and there is something very weird going on. The options()$work_citations does not change in one case, but does in the other. BUT, the first instance of modifying work_citations works.

When using knit2html button (test_knit2html.md), the work_citations option does not get updated. I even tried putting this in a for loop to make sure that it wasn't due to being in the sapply, and it still doesnt update.

However, when I call knitr from the command line, the work_citations option does get updated properly. I've been trying to figure this out all morning, and not having any luck. I am going to submit this as an issue to yihui and rstudio as well, because this seems odd.

I put up the example with both outputs here:

https://gist.github.com/3918301

[rmflight]

I've tried to recreate this behavior independently by creating a package that basically only modifies one option variable, with no luck. You can see my effort here: https://github.com/rmflight/testOptionManipulation

[cboettig]

Thanks for writing! Yeah, I know, it's on my issues list http://github.com/cboettig/knitcitations/issues

Planning a re-write soon which should be able to work around this. On Oct 19, 2012 8:24 AM, "Robert M Flight" notifications@github.com wrote:

I've tried to recreate this behavior independently by creating a package that basically only modifies one option variable, with no luck. You can see my effort here: https://github.com/rmflight/testOptionManipulation

— Reply to this email directly or view it on GitHubhttps://github.com/cboettig/knitcitations/issues/14#issuecomment-9605075.

[rmflight]

So do you know why this happens? I'm curious why it should be happening in knitcitations and not when I write a package that tries to do the same basic manipulation of the option space.

I had also tried using "global" variables to store stuff, and didn't have any luck with that either.

[rmflight]

Hmm, just discovered that knitr will let you make assignments in an inline statement. So I could imagine doing something like having a function that updates a bibliographic object, and as a side effect prints the inline citation

https://gist.github.com/3919523

[cboettig]

I haven't figured out why rstudio's knit2html gives different results, but it has something to do with the way it handles environments set by options. My use of "options" isn't really best-practice, just editing options in the global environment. I can set an explicit new environment for knitcitations to use instead, or may use an external file (e.g. writing to a bibtex file) to store the list of things cited so far.

Re the inline statement, yes indeed, this is in fact how I expect people to use the "citep()" and "citet()" functions in kintr, which return inline citations (parenthetical citation or textual citation) and update the biblographic object.

See https://github.com/cboettig/knitcitations/blob/master/inst/examples/citations.Rmd#L148

On Fri, Oct 19, 2012 at 10:36 AM, Robert M Flight notifications@github.comwrote:

Hmm, just discovered that knitr will let you make assignments in an inlinestatement. So I could imagine doing something like having a function that updates a bibliographic object, and as a side effect prints the inline citation

https://gist.github.com/3919523

— Reply to this email directly or view it on GitHubhttps://github.com/cboettig/knitcitations/issues/14#issuecomment-9609460.

Carl Boettiger UC Davis http://www.carlboettiger.info/

[rmflight]

No, I'm saying you could use an assignment inline to update the object, then you don't have to worry about creating your own environment (although that does sound like an interesting idea).

eg

r I(inObj <- insertStoreText(inObj, "hello world"))

Here insertStoreText prints the "hello world" as a side effect, while updating inObj at the same time (see https://gist.github.com/3919523 as a trivial example of this).

I never thought of this before because all of yihui's inline examples are just printing previously saved objects, but it turns out there is no problem with putting in full assignments as well. This way the bibliography object is guaranteed to be local, and updated, and provides a lot of flexibility for the user, and for you, because all of your functions then require the user to pass in the object that has the stored info for the final bibliography.

[cboettig]

Ah, sorry for the confusion.

It's an interesting idea, but I assumed most users would want the inline call to be as concise as possible, e.g. r citep("Halpern2006") rather than r bib_list <- citep("Halpern2006"). Or maybe I'm still missing something.

(Actually I'd like to do away with the quotes too, but it's difficult to handle both DOIs and bibentries objects if I do so, see: https://github.com/cboettig/knitcitations/issues/10)

On Fri, Oct 19, 2012 at 11:14 AM, Robert M Flight notifications@github.comwrote:

No, I'm saying you could use an assignment inline to update the object, then you don't have to worry about creating your own environment (although that does sound like an interesting idea).

eg

r I(inObj <- insertStoreText(inObj, "hello world"))

Here insertStoreText prints the "hello world" as a side effect, while updating inObj at the same time (see https://gist.github.com/3919523 as a trivial example of this).

I never thought of this before because all of yihui's inline examples are just printing previously saved objects, but it turns out there is no problem with putting in full assignments as well. This way the bibliography object is guaranteed to be local, and updated, and provides a lot of flexibility for the user, and for you, because all of your functions then require the user to pass in the object that has the stored info for the final bibliography.

— Reply to this email directly or view it on GitHubhttps://github.com/cboettig/knitcitations/issues/14#issuecomment-9610901.

Carl Boettiger UC Davis http://www.carlboettiger.info/

[rmflight]

Well, I tried using an environment, and I still get the same differences I did when we were using options. Could you try it and see if it does the same thing for you Carl? I have a branch based more or less on your original code that now uses environments. https://github.com/rmflight/knitcitations/tree/originalCode

What is really weird about this is it inserts the first reference, and then refuses to insert any following references.

You can see the differences in https://github.com/rmflight/knitcitations/blob/originalCode/test_globalObj.md, and https://github.com/rmflight/knitcitations/blob/originalCode/test2_md.md, which are knit2html button and knitr, respectively.

I know its accessing the environment at least once.

[yihui]

I looked at this problem for a while, and could not understand it either...