-
Notifications
You must be signed in to change notification settings - Fork 6
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
Unexpected END_OF_INPUT error (URL parsing?) #3
Comments
Thanks for the report. As you suspected, the error is caused by the symbols encoded with the html % codes. If the "%-encoded letters are replaced with the actual letters, as in
In fact, the command succeeds also with the percent-encoded url - the error comes only when the result is printed, since the percents confuse the default print method. This is a known conundrum with bibentry objects. If you assign the result, you can then print it in various styles:
(edit on 2018-03-01 - the example with percents gives errors - I somehow messed up the testing of the above code and didn't get errors the other day.) Would this resolve your problem? |
Thanks for following up, but the workaround doesn't resolve my problem: a) The percents are needed to make the URL clearly distinguishable as having single spaces [1] b) I am actually using the insertRef macro in roxygen documentation per Rdpack recommendation. c) I think the parameter option is "format"? d) The output of "print(a, format="latex")" still has a superflous period and closing curly brace that confuses LaTeX. The presence of these characters may be the original trigger for the other problems. [1] https://stackoverflow.com/questions/497908/is-a-url-allowed-to-contain-a-space |
As you get the error when using insertRef macro, that is a bug which I will need to sort out somehow. I think that the argument for print is "style", see |
I am seeing the both the error and spurious brace+period with several versions of your print statement [1]. As for building the help in html... the warning messages and extra brace are in the html print output anyway. [1] test2.zip |
I pushed a draft solution for the problem - insertRef should now work smoothly with percent encoded entries. Could you check? For the moment I have actually included the reference from your example in REFERENCES.bib in Rdpack and it is cited in Please note that I have not touched |
v0.5-6 fixed |
Looking forward to v0.6 so I can add a minimum version dependency in my DESCRIPTION file. Or, use two-dot version notation... |
I cleaned up a little bit and updated also get_bibentries(), further details are oin NEWS. By the way, do you use get_bibentries() or just came to it in the process of investigating the bug concerning insertRef? I will bump the version to 0.6 once I do a further round of testing or get a confirmation from you that it looks ok. If you are about to submit a package depending on it on CRAN, I will publish it but otherwise I would prefer to delay a little bit since I had two releases in less than two months. |
I only used get_bibentries to illustrate what appeared to be the same problem, but apparently was not.
I think I have a bit of work to do before releasing so no rush on my account, but neither can I see the benefit of using dash versioning over double dot versioning in R packages since R doesn't interpret it. Could be a good reason for it... I just don't see why 0.5-6 is better than 0.5.6.
--
Sent from my phone. Please excuse my brevity.
…On March 3, 2018 9:14:52 AM PST, "Georgi N. Boshnakov" ***@***.***> wrote:
I cleaned up a little bit and updated also get_bibentries(), further
details are oin NEWS. By the way, do you use get_bibentries() or just
came to it in the process of investigating the bug concerning
insertRef?
I will bump the version to 0.6 once I do a further round of testing or
get a confirmation from you that it looks ok. If you are about to
submit a package depending on it on CRAN, I will publish it but
otherwise I would prefer to delay a little bit since I had two releases
in less than two months.
|
For R it doesn't matter, 0.5.6 and 0.5-6 are the same, you can use dots. I probably didn't know that 8-10 years ago when I started using it and equally there seems little point in changing it now. Thanks for going into the trouble of searching for the cause of the warnings. If you wonder what is the difference between get_bibentries and insert_ref - here It is. insertRef needs to convert the reference to Rd format by definition. I actually think that the bug there is in tools::toRd, which I use to do that. There are two reasons why I thing this is so. First, WRE explicitly stated that special letters should be percent encoded and the percents escaped. Second, leaving the percents unescaped in Rd text creates invalid Rd text, as you discovered. Even more,there is a case to argue that toRd should actually percent encoded special symbols. On the other hand, get_bibentries creates a bibentry object and in principle it is not clear if percents should be escaped there. Actually, what matters is how these are exported by the print methods for the different styles. There is no universally applicable solutions since some hinted styles do the escaping themselves, but most simply transfer the content of the URL field. |
After the debugging and improvement of get_bibentries() prompted by your comments, I switched \insert_ref to calling it. \insertRef now handles percent encoded URL's everywhere, not only in the url field. It is sufficient to require Rdpack (>= 0.6). Thanks again. |
The attached zip file contains an RStudio notebook file illustrating the error.
If I remove the url field from the bibtex entry, get_bibentries works without a problem, so it looks to me like there is a parsing problem with URLs (perhaps when % encoded characters are present?)
test.zip
The text was updated successfully, but these errors were encountered: