Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra { around inherited href tags #778

Closed
isteves opened this issue Aug 10, 2018 · 10 comments
Closed

Extra { around inherited href tags #778

isteves opened this issue Aug 10, 2018 · 10 comments

Comments

@isteves
Copy link

@isteves isteves commented Aug 10, 2018

I've been getting the following error when running devtools::check:

checking Rd files ... WARNING
prepare_Rd: bad markup (extra space?) at test.Rd:11:113
prepare_Rd: bad markup (extra space?) at test.Rd:14:38
prepare_Rd: bad markup (extra space?) at test.Rd:15:48

These lines all contain links that have been inherited via @inheritParams. They work fine in the original package (usethis::create_project(), rstudio argument) but for some reason get an extra { when they're inherited:

\href{https://here.r-lib.org}{here}

versus

\href{{https://here.r-lib.org}{here}} 

I've created a minimal package that isolates the problem. I'm using roxygen version 6.1.0.

@isteves

This comment has been hidden.

@hadley

This comment has been hidden.

@isteves

This comment has been hidden.

@mjsteinbaugh

This comment has been hidden.

@sctyner

This comment has been hidden.

sctyner pushed a commit to sctyner/memer that referenced this issue Apr 16, 2019
jennybc added a commit to r-lib/gargle that referenced this issue Jun 18, 2019
The hyperlink causes trouble in client packages using @inheritParams

r-lib/roxygen2#866
r-lib/roxygen2#778
@hadley
Copy link
Member

@hadley hadley commented Aug 13, 2019

Minimal reprex using internal functions:

get_params <- function(pkg, fun) {
  rd <- roxygen2:::get_rd(fun, pkg)
  roxygen2:::topic_params.Rd(rd)
}

cat(get_params("usethis", "create_project")[["rstudio"]])
#> If \code{TRUE}, calls \code{\link[=use_rstudio]{use_rstudio()}} to make the new package or
#> project into an \href{{https://support.rstudio.com/hc/en-us/articles/200526207-Using-Projects}{RStudio Project}}.
#> If \code{FALSE} and a non-package project, a sentinel \code{.here} file is placed so
#> that the directory can be recognized as a project by the
#> \href{{https://here.r-lib.org}{here}} or
#> \href{{https://rprojroot.r-lib.org}{rprojroot}} packages.
cat(get_params("tidyr", "unnest")[["..."]])
#> Name-variable pairs of the form \code{new_col = c(col1, col2, col3)},
#> that describe how you wish to nest existing columns into new columns.
#> The right hand side can be any expression supported by tidyselect.
#> 
#> \Sexpr[results=rd, stage=render]{lifecycle::badge("deprecated")}: previously you could write \code{df \%>\% nest(x, y, z)}
#> and \code{df \%>\% unnest(x, y, z)}. Convert to \code{df \%>\% nest(data = c(x, y, z))}.
#> and \code{df \%>\% unnest(c(x, y, z))}.
#> 
#> If you previously created new variable in \code{unnest()} you'll now need to
#> do it explicitly with \code{mutate()}. Convert \code{df \%>\% unnest(y = fun(x, y, z))}
#> to \code{df \%>\% mutate(y = fun(x, y, z)) \%>\% unnest(y)}.

Interestingly it's specifically \href{} that's the problem; \code{}, \link{}, and \Sexpr{} are all fine.

@hadley
Copy link
Member

@hadley hadley commented Aug 13, 2019

Even more minimal reprex:

tools::parse_Rd(textConnection("\\href{a}{b}"), fragment = TRUE)
#> \href{{a}{b}}

Created on 2019-08-13 by the reprex package (v0.3.0)

So this looks like a base R problem with the Rd pretty printer. Is anyone interesting in tracking this down further and filing a bug report with R-core?

@hadley hadley added this to the v6.2.0 milestone Aug 22, 2019
@andrewmarx
Copy link

@andrewmarx andrewmarx commented Aug 26, 2019

I randomly came across this open issue and am exploring it out of sheer curiosity. I may or may not be able to track it down all the way. In case someone else is interested in trying: so far I've traced it to parseRd() in gramRd.c, but this is now getting into lexical analysis which is not something I'm experienced with. One interesting thing is that the keywords[] array in this file has different integers assigned for different possible tokens:

...

/* This macro takes one verbatim and one LaTeX-like argument. */

{ "\\href",    VERBLATEX },
    
/* This macro takes three LaTeX-like arguments. */

{ "\\ifelse",  LATEXMACRO3 },

/* These macros take one optional bracketed option and always take 
   one LaTeX-like argument */

{ "\\link",    OPTMACRO },

/* These markup macros require an R-like text argument */

{ "\\code",    RCODEMACRO },
{ "\\dontshow",RCODEMACRO },
{ "\\donttest",RCODEMACRO },
{ "\\testonly",RCODEMACRO },

/* This macro takes one optional bracketed option and one R-like argument */

{ "\\Sexpr",   SEXPR },

...

Which might explain why \code{}, \link{}, and \Sexpr{} work; they are handled differently by the parser.

@andrewmarx
Copy link

@andrewmarx andrewmarx commented Aug 27, 2019

I spent a little more time on it this morning, and am reasonably sure the cause is in yyparse() in gramRd.c. Unfortunately, this function (Bison parser) looks pretty involved and I don't have time to figure out how it works. Whether it is an actual issue in this function (or one of the ones it calls), or if the mapped value in the keywords[] array just needs to be changed, I don't know.

For whoever takes this up, the values in the keywords[] array are being mapped to values in the yytranslate[] array, which are then used in the switch statements in yyparse(). In the case of "\href", the keywords[] value is 277, which gives 22 from yytranslate[]. To get to where I suspect you need to be, look for this spot in gramRd.c:

  case 22:

    { (yyval) = (yyvsp[0]); }

@hadley
Copy link
Member

@hadley hadley commented Sep 12, 2019

Actually I think the problem might be a bit simpler — as.character.Rd contains a vector called TWOARG and adding \\href seems to fix the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants