Possible \uxxx typos in documents

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible \uxxx typos in documents

Korpela Mikko (MML)
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@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}{

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

In base R: argument `list` does not accept lists

Johannes Rauh
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: In base R: argument `list` does not accept lists

Duncan Murdoch-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: In base R: argument `list` does not accept lists

Ista Zahn
On Fri, Apr 13, 2018 at 3:51 PM, Duncan Murdoch
<[hidden email]> 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
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel