I found a few occurrences of "\uxxx" which should probably have
one more "x". A patch follows:
Index: doc/manual/R-ints.texi
===================================================================
--- doc/manual/R-ints.texi (revision 74580)
+++ doc/manual/R-ints.texi (working copy)
@@ -1277,11 +1277,11 @@
we have to a universal format. For those that do not (for example those
lacking a powerful enough @code{iconv}), it is likely that they work in
Latin-1, the old @R{} assumption. Then the parser can return a
-UTF-8-encoded string if it encounters a @samp{\uxxx} escape for a
+UTF-8-encoded string if it encounters a @samp{\uxxxx} escape for a
Unicode point that cannot be represented in the current charset. (This
needs MBCS support, and was only enabled at footnote{See define
@code{USE_UTF8_IF_POSSIBLE} in file @file{src/main/gram.c}.} on
-Windows.) This is enabled for all platforms, and a @samp{\uxxx} or
+Windows.) This is enabled for all platforms, and a @samp{\uxxxx} or
@samp{\Uxxxxxxxx} escape ensures that the parsed string will be marked
as UTF-8.
Index: src/library/base/man/iconv.Rd
===================================================================
--- src/library/base/man/iconv.Rd (revision 74580)
+++ src/library/base/man/iconv.Rd (working copy)
@@ -95,7 +95,7 @@
Some of the implementations have interesting extra encodings: for
example GNU \samp{libiconv} allows \code{to = "C99"} to use
- \code{\\uxxx} escapes for non-ASCII characters.
+ \code{\\uxxxx} escapes for non-ASCII characters.
}
\section{Byte Order Marks}{
Possible \uxxx typos in documents
4 messages · Korpela Mikko (MML), Johannes Rauh, Duncan Murdoch +1 more
1 day later
The function `base::rm` has an argument that is named `list`. However, if a list is passed as `list` to `rm` (e.g.: `rm(list = list("x", "y"))`), an error is raised: "invalid first argument".
Agreed, the documentation says that `list` should be "a character vector naming objects to be removed." Still, wouldn't it make sense to allow a list of characters as an argument?
The other alternative to make things consistent would be to rename the argument, but that would break compatibility, of course.
Best
Johannes
On 13/04/2018 7:21 AM, Johannes Rauh wrote:
The function `base::rm` has an argument that is named `list`. However, if a list is passed as `list` to `rm` (e.g.: `rm(list = list("x", "y"))`), an error is raised: "invalid first argument".
Agreed, the documentation says that `list` should be "a character vector naming objects to be removed." Still, wouldn't it make sense to allow a list of characters as an argument?
The other alternative to make things consistent would be to rename the argument, but that would break compatibility, of course.
There are other functions (data(), save(), remove(), package.skeleton(),
etc.) that use the convention that "list" names a character vector full
of names, others where variations on that name ("affinity.list",
"pkglist") have the same purpose, and still others where "list" takes a
different kind of object entirely (untar(), unzip()). I couldn't find
any examples where an argument named "list" takes a list as a value.
There really isn't any substitute for reading the documentation for any
function you choose to use.
Duncan Murdoch
On Fri, Apr 13, 2018 at 3:51 PM, Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:
On 13/04/2018 7:21 AM, Johannes Rauh wrote:
The function `base::rm` has an argument that is named `list`. However, if
a list is passed as `list` to `rm` (e.g.: `rm(list = list("x", "y"))`), an
error is raised: "invalid first argument".
Agreed, the documentation says that `list` should be "a character vector
naming objects to be removed." Still, wouldn't it make sense to allow a
list of characters as an argument?
The other alternative to make things consistent would be to rename the
argument, but that would break compatibility, of course.
There are other functions (data(), save(), remove(), package.skeleton(),
etc.) that use the convention that "list" names a character vector full of
names, others where variations on that name ("affinity.list", "pkglist")
have the same purpose, and still others where "list" takes a different kind
of object entirely (untar(), unzip()). I couldn't find any examples where
an argument named "list" takes a list as a value.
There really isn't any substitute for reading the documentation for any
function you choose to use.
Maybe, though if so it's at least a little ironic that you make an appeal to consistency in support of the status quo. "Read the docs" you say, because if you do you'll see that "list" never means list, and then you won't have to read the docs because you have learned the convention. Maybe. On the other hand, the OP wasn't so much reporting a bug as making a feature request. Really, why shouldn't the "list" argument of rm, data, save, remove, etc. accept either a list of a vector? I can't think of anything it would hurt, and it would help people who assume (reasonably enough IMO) that an argument named "list" will accept a list as as a valid value? Best, Ista
Duncan Murdoch
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel