Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
work around failures in
utf8_width()
. @patperry: Would you support …
…a version of `utf8_width()` that always returns a number? - Work around failing CRAN tests on Windows.
- Loading branch information
d00c11f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you insist on
encode = FALSE
? This code returns1
forget_extent("\n")
. Is that what you want?d00c11f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw make sure you are using the latest version of utf8 (1.1.0). I fixed a bug in utf8_width in C locale, and added more precise control over assumed output capabilities with
utf8
arg toutf8_width
d00c11f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x
should never be"\n"
here, or anything un-printable. But I'm not sure what happens on Windows.CRAN was seeing check errors for pillar on Windows, I needed a quick fix. I need to take a closer look to understand how
utf8_width()
could becomeNA
. Anyway, for this routine I don't really care: A bad width "only" messes up the output, but anNA
width just breaks everything.d00c11f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-ASCII strings get NA width in C locale, unless
utf8
arg isTRUE
. With v1.1.0, you can specifyutf8_width(, utf8=TRUE)
to ignore the current locale when computing width. This might fix yourNA
issues.d00c11f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, thanks.