inline R in blog yaml isn't executed on listing page

[harrig12]

I have a blog post with a description that contains inline r (to estimate reading time)

it renders nicely for the post itself

but not in the listing page!

here's the yml of my post's index.qmd:

---
draft: false
title: A nice blog post
description: |
  Reading time: `r ifelse(file.size("index.qmd")/2000 <= 1, '<1 minute', paste0(round(file.size("index.qmd")/2000), ' minutes'))`
---

Any idea of how I can fix the listing?

[harrig12]

Similarly, adding today's date via inline r seems to have some funky output
(I know this is not recommended for blogs, but it still seems to be undesirable behaviour)

yml

---
draft: false
title: A nice blog post
date: "`r date()`"
image: thumbnail.jpg
---

post result

listing result

[dragonstyle]

I have a blog post with a description that contains inline r (to estimate reading time)

I'll have a look - agree that this isn't desirable. Side note - we do compute reading and can display that in the blog listing:

listing:
  type: default
  fields: [title, subtitle, author, description, date, image, reading-time]

Similarly, adding today's date via inline r seems to have some funky output

For this we would definitely prefer that you use the built in functionality that does the same thing (though in a language agnostic way). More about the options here:

https://quarto.org/docs/reference/dates.html

Agree that ideally this would work, but date is a use case that we could discourage and hope the built in support offers functionality sufficient to replace it.

[mcanouil]

@dragonstyle is this listing preview issue related to Font Awesome icons not showing up (quarto-ext/fontawesome#7)?

[dragonstyle]

I think this one may be different - I have a theory that the font awesome issue is that we're actually a little 'too smart' (by my recommendation :( ) in that LUA filter - we only inject the fontaweome CSS / fonts when we see that a shortcode was used on the page. I think the listing page isn't getting that CSS / font because we bring fully rendered HTML into the page in a post processor, and so LUA never sees the shortcode.

I haven't had time to test this yet, but I think if you add a FA element to a listing page itself, the ones in posts will start working (or alternatively you could just see if the listing contents include properly rendered FA HTML that we just aren't styling).

There are very fancy fixes for this in the long run (pages noting their dependencies and listing pages merging them) but in the short run we could also just make the font awesome dependency injection a little less smart :).

[mcanouil]

Thanks, I assumed this was something related to how CSS was injected (quarto-ext/fontawesome#7 (comment)), but was wondering with this issue if it was only that.

[dragonstyle]

Nice you completely nailed it! I'm not totally confident that is the only issue but I think it will be the big one...