news markdown incorrectly rendered to html

[tdhock]

NEWS items with indented markdown render ok on github https://github.com/Rdatatable/data.table/blob/HEAD/NEWS.md but not on https://r-datatable.com/news/index.html

above left we see unexpected backticks at the end of news items 3 and 4, and Additionally… in item 4 is rendered as code.

source code is https://raw.githubusercontent.com/Rdatatable/data.table/596f65d53efee3918d62e9dddb69acda37778876/NEWS.md

3. Rolling functions `frollmean` and `frollsum` distinguish `Inf`/`-Inf` from `NA` to match the same rules as base R when `algo="fast"` (previously they were considered the same). If your input into those functions has `Inf` or `-Inf` then you will be affected by this change. As a result, the argument that controls the handling of `NA`s has been renamed from `hasNA` to `has.nf` (_has non-finite_). `hasNA` continues to work with a warning, for now.

    ```r
    ## before
    frollsum(c(1,2,3,Inf,5,6), 2)
    #[1] NA  3  5 NA NA 11

    ## now
    frollsum(c(1,2,3,Inf,5,6), 2)
    #[1]  NA   3   5 Inf Inf  11
    ```

4. `frollapply` result is not coerced to numeric anymore. Users' code could possibly break if it depends on forced coercion of input/output to numeric type.

    ```r
    ## before
    frollapply(c(F,T,F,F,F,T), 2, any)
    #[1] NA  1  1  0  0  1

    ## now
    frollapply(c(F,T,F,F,F,T), 2, any)
    #[1]    NA  TRUE  TRUE FALSE FALSE  TRUE
    ```

    Additionally argument names in `frollapply` has been renamed from `x` to `X` and `n` to `N` to avoid conflicts with common argument names that may be passed to `...`, aligning to base R API of `lapply`. `x` and `n` continue to work with a warning, for now.

5. Negative and missing values of `n` argument of adaptive rolling functions trigger an error.

how to fix so it renders ok in both places?

[MichaelChirico]

There's actually three places we need it to render:

1. GitHub [GitHub renderer]
2. gitlab [pkgdown renderer]
3. CRAN [? renderer]

#7511 was about NEWS being ugly on CRAN

[aksh08022006]

By looking here, I think the rendering issue might be coming from fenced code blocks inside numbered list items in NEWS.md. GitHub seems to handle this fine, but pkgdown / CRAN’s Pandoc pipeline appears to be stricter and treats the closing ``` as literal text, which then causes the following paragraph to be rendered as code.

A possible fix (that should be portable across GitHub, pkgdown, and CRAN) would be to indent fenced code blocks by 4 spaces relative to the list item, with blank lines before and after, so they are unambiguously scoped to the list item. Alternatively, we could switch to indented code blocks inside lists, though that would drop syntax highlighting.

Before opening a PR, I wanted to check:

Is indenting fenced code blocks within list items the preferred approach for NEWS.md here?

Or would you prefer converting these examples to indented code blocks for maximum robustness?
i could be wrong plz correct me if i am .

If this approach sounds good, I’m happy to prepare a small PR updating the affected entries and keeping the rest of the file unchanged.

[aitap]

The news on CRAN should be fine after the 1.18.2 release because CRAN renders NEWS.md using Pandoc (curl https://cran.r-project.org/web/packages/data.table/news/news.html | grep 'meta name="generator"' ⇒ content="pandoc") and we merged Pandoc fixes in #7518 and back-ported the fix.

The news on the website should be fine after #7534 because litedown uses commonmark, and litedown::pkg_news() |> litedown::fuse(output = 'news.html') seems to work fine.

[ben-schwen]

Note that the NEWS on the website has not been rendered since some weeks since our Gitlab CI is broken after we switched vignette building to litedown

[aksh08022006]

it sounds like:
To improve the GitHub readability without affecting the existing CRAN/pkgdown pipelines, I’m planning to open a small PR that:

Indents the affected fenced code blocks by 4 spaces so they are clearly scoped within their list items.

Keeps the content identical, only adjusting Markdown structure.

Limits changes strictly to the problematic entries.

Please let me know if this approach is acceptable, and I’ll prepare the PR accordingly.