Am 07.11.23 um 23:59 schrieb Sebastian Meyer:
This is a known issue already reported to the Rdpack maintainer. In some
cases, the Rd code generated by Rdpack's macros contains unnecessary
braces that trigger the check note because they match the pattern
"text{text}" that detects common mistakes
Am 07.11.23 um 23:00 schrieb Ivan Krylov:
On Tue, 7 Nov 2023 17:13:05 +0100
Martin Becker wrote:
More specifically, a 'Lost braces' NOTE is issued (at least
sometimes) when using the \insertRef{...}{...} command from the
Rdpack package.
Does anything change if you use the development version
This is a known issue already reported to the Rdpack maintainer. In some
cases, the Rd code generated by Rdpack's macros contains unnecessary
braces that trigger the check note because they match the pattern
"text{text}" that detects common mistakes like "code{x}" (missing an
escape for the mac
On Tue, 7 Nov 2023 17:13:05 +0100
Martin Becker wrote:
> More specifically, a 'Lost braces' NOTE is issued (at least
> sometimes) when using the \insertRef{...}{...} command from the
> Rdpack package.
Does anything change if you use the development version of Rdpack (not
currently on CRAN)? Appa
Dear developers,
while preparing to submit a package to CRAN, I noticed that a check for
lost braces in Rd files (which is enabled in the current r-devel when
checking with the '--as-cran' option) seems to return false positives.
More specifically, a 'Lost braces' NOTE is issued (at least som
> Michael Chirico
> on Mon, 6 Nov 2023 23:18:40 -0800 writes:
> Thanks Martin. My hang-up was not on what the outcome of as.complex(NA)
> should be, but rather, how I should read code like c(x, y) generally. Till
> now, I have thought of it like 'c(x, y)' is c(as(x, typeof
> peter dalgaard
> on Mon, 6 Nov 2023 11:59:51 +0100 writes:
> Hmm, it is not actually at odds with help(c), it is just that the
autocoercion works different that it used to, so that
> as.complex(NA) == as.complex(NA_real) == NA_real_+0i)
> which now differs from
>
