Inline references don't work

[cdhowlett]

This code is a suitable test harness:

https://riptutorial.com/r/example/25031/inline-references

It correctly uses inline references in the yaml to generate citations and a bibliography using tufte handout. However, changing the output to tint::tintPdf results in ? in place of the citations, and no bibliography.

[eddelbuettel]

There also used to be a way to embed the generated code from the blg (or was it bbl ?) file in the header. I liked that a lot.

We had to turn it all off and revert to explicit bibtex reference files; the changes was (IIRC) due to how RMarkdown and pandoc interact. "It's the hand we're being dealt." There is really nothing much I can suggest here, apart from not using the tint package whose processing are fairly closely tied to the rmarkdown flow. If you want to use "pure" Markdown process you may have to get your styling another way.

It is probably fixable (in the more abstract "well all languages are equivalent and Turing-complete" sense) but I don't have time for it, and I am not too bothered by having external .bib files -- I do anyway as like being able to use plain LaTeX as well.

[eddelbuettel]

Actually, the file is not a "suitable test harness" as it fails to enable tint. Doh.

Using

---
title: "Writing an academic paper in R"
author: "Author"
date: "Date"
bibliography: tintBibDemo.bib
link-citations: yes
output: tint::tintPdf
toc: yes
---

# Introduction

`@Meyer2000` results in @Meyer2000. 

`@Meyer2000 [p. 328]` results in @Meyer2000 [p. 328]

`[@Meyer2000]` results in [@Meyer2000]

`[-@Meyer2000]` results in [-@Meyer2000]

# Summary

# References

with a suitably tintBibDemo.bib as e.g. in

@Article{Meyer2000,
  author =       {Bernd Meyer},
  title =        {A Constraint-Based Framework for Diagrammatic
                  Reasoning},
  journal =      {Applied Artificial Intelligence},
  year =         2000,
  volume =       14,
  number =       4,
  pages =        {}
}

works as you'd expect:

One weirdness was that on my reasonably current machine (Ubuntu 19.10) the default pandoc-citeproc was too old, so I had to link the one that ships with RStudio in my $PATH to process this (outside of RStudio, that is).

[cdhowlett]

Perhaps my report was a little hurried and has been misunderstood.

The code fragment I pointed to has

output:
pdf_document

in the yaml. This works fine.

If I change this to

output:
tufte::tufte_handout

It also works fine.

However, if I change that line to

output:
tint::tintPdf

The citations turn into question marks and the bibliography disappears.

It was my understanding that tint was quite heavily based on tufte, and so it was likely to be a relatively minor one line breakage somewhere. Obviously if you're not interested in fixing it that's your prerogative - it's your project after all.

[cdhowlett]

I should add in case it's not clear that I am happily using tint without this feature, so tint is loaded in my environment. I just can't get it to generate a bibliography and citations from inline references, where this works for tufte handout and standard pdf output.

Thanks anyway for your great work.

[eddelbuettel]

You assume all RMarkdown styles are interchangeable. They are not. There is parsing code involved.

So if tufte::tufte_handout is different from tint::tinPdf then you have two choices:

• propose, and if agreed, develop a PR to carry behavior over from the former to the latter
• use the former only

What you have not done is demontrate that tintPdf fails at something it documents or promises as working. It does what it is supposed to do.

[eddelbuettel]

As I said at the outset, how bibliographic information is passed to (ultimately) pandoc has changed over the years. But documented examples worked and still do.

We never suggested the style you found would work. I understand that it may have merit in a pure YAML world. That's just not my use case and itch to scratch. I have kept references in bib files for a few decades now.

[cdhowlett]

Yes that's perfectly true. I did not set out to demonstrate that tintPdf fails at anything. On the contrary, I'm very happy to find it, as it's output is very attractive.

I simply saw that it was documented by the core R team that inline references were possible, found that these didn't work in tint as I expected, and brought that to your attention.

For now developing a PR myself to fix this is beyond my skills - I have close to none of the necessary expertise.

I realise this is pretty niche - most people will happily use an external bib file. Nonetheless, perhaps it would be worth documenting somewhere that this doesn't work, so someone else might avoid the hours of head scratching I've just subjected myself to.

Anyway, thanks again for your attention - I'll go back to happily using your work in ways it is intended to function!

[eddelbuettel]

You continue to gloss over the fact that different RMarkdown styles are, well, different. So "documented by the core R team" is doubly wrong. R Core never writes about RMarkdown as that is a (mostly RStudio plus contributors) extension. Second, not documented for this package.

To be blunt, you can't walk into a Chevy dealership and complain that is doesn't hold the road like your neighbor's imported sportscar might. These are different cars by different makers.

But yes, tintPdf is quite enjoyable, and I use it too. And I also stick to the Natbib citation style as I sometime have to turn my writeups in Rmd into tex files handed to someone else. Cheers.

[cdhowlett]

Fair enough.

I'll simply respond by saying you continue to suggest I'm complaining when I'm not.

I came in to this conversation thinking that it was an oversight that inline references don't do what I expected. I now understand it was my expectations that were at fault.

And that's fine. I just wish I'd had an easier way to find that out.

Anyway, again, thanks for tint. I'd really better get back to using it.

[eddelbuettel]

Computing is continual learning. I was merely trying to provide feedback for that process.

For generic questions of 'how do I ...' or 'Could one not consider ...' maybe StackOverflow is better. Issue tickets are very specifically for 'bug reports' and alike, so the tone and context are different. Don't let that deter you, they are really good for actual bug reports or feature requests.