Re: [Rd] (PR#11537) help (using ?) does not handle trailing whitespace
By whitespace, I mean either a space or tab (preceding the newline).
I'm using ESS:
ess-version's value is "5.3.6"
GNU Emacs 21.4.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2007-08-28 on terranova, modified by Debian
I have the following in my .emacs:
(load "ess-5.3.6/lisp/ess-site")
(setq ess-tab-always-indent nil)
(setq ess-fancy-comments nil)
I have not edited ess-site.el
On Fri, May 30, 2008 at 12:26 PM, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> We don't know how to reproduce this: 'whitespace' is not specific enough.
>
> R's tokenizer breaks input at spaces, so a space would never be part of that
> expression. And tabs don't even get to the parser in interactive use, and
> you cannot mean a newline. So exactly what do you mean by 'whitespace'?
>
> The character in your email as received here is an ASCII space, and that is
> used to end the token on all my systems. That's not to say that you didn't
> type something else that looks like a space (e.g. a nbspace) since email
> systems are fickle.
>
> None of my guesses worked, so we need precise reproduction instructions.
>
> On Thu, 29 May 2008, [EMAIL PROTECTED] wrote:
>
>>> ?agrep
>>>
>>
>> Results in:
>>
>> No documentation for 'agrep ' in specified packages and libraries:
>> you could try 'help.search("agrep ")'
>>
>> There is white space after agrep, that ? doesn't ignore.
>>
>>
>> --please do not edit the information below--
>>
>> Version:
>> platform = i486-pc-linux-gnu
>> arch = i486
>> os = linux-gnu
>> system = i486, linux-gnu
>> status =
>> major = 2
>> minor = 7.0
>> year = 2008
>> month = 04
>> day = 22
>> svn rev = 45424
>> language = R
>> version.string = R version 2.7.0 (2008-04-22)
>>
>> Locale:
>>
>> LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
>>
>> Search Path:
>> .GlobalEnv, package:stats, package:graphics, package:grDevices,
>> package:utils, package:datasets, package:showStructure, package:Rcode,
>> package:splus2R, package:methods, Autoloads, package:base
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: plot.acf often produces too long titles (PR#11545)
--=_Part_12871_19030521.1212173232092 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhlIHByb2JsZW06IGN1cnJlbnRseSwgaW4gY3Jvc3MtY29ycmVsYXRpb24gcGxvdHMgbWFpbiB0 aXRsZSBjYXB0aW9ucwphcmUgY29uc3RydWN0ZWQgb2YgMiBzZXJpZXMgbmFtZXMgc2VwYXJhdGVk IGJ5ICcmJyBzeW1ib2wuIFN1Y2gKY2FwdGlvbnMgb2Z0ZW4gb2NjdXB5IHRvbyBtdWNoIGhvcml6 b250YWwgc3BhY2UgYW5kIGRvbid0IGZpdCBpbgpwbG90LiBIZXJlIGlzIGFuIGV4YW1wbGUgd2l0 aCByZWFsLWxpZmUgc2VyaWVzIG5hbWVzIGFuZCBwbG90CmRpbWVuc2lvbnM6CgpkYXRhIDwtIGNi aW5kKCfQp9C40YHQu9C+INC/0L7QttCw0YDQvtCyJyAgPSBhcmltYS5zaW0obiA9IDEwMCwgbGlz dChhciA9IDAuNSkpLAogICAgICAgICAgICAgJ9CY0L3QtC4g0J3QtdGB0YLQtdGA0L7QstCwJyA9 IGFyaW1hLnNpbShuID0gMTAwLCBsaXN0KGFyID0gMC4xKSkpCngxMSh3aWR0aCA9IDQuOCwgaGVp Z2h0ID0gNC4yKQphY2YoZGF0YSwgbWFyID0gYygzLCAzLCAzLCAxKSArIDAuMSwgY2V4Lm1haW4g PSAxKQoKSW4gc3VjaCBhIGNhc2Ugb25lIG1heSB3YW50IHRvIHNwbGl0IGNhcHRpb25zIGluIHR3 byBsaW5lcyAoZWFjaApzZXJpZXMgbmFtZSBvbiBpdHMgc2VwYXJhdGUgbGluZSkuIEkgYXR0YWNo IGEgcGF0Y2ggd2hpY2ggYWRkcyBhbgpvcHRpb24gdG8gZG8gc28uIFRoZSBwYXRjaCBkb2VzIDIg dGhpbmdzOgoKMSkgQWRkcyBuZXcgYXJndW1lbnQgbWFpbi5zZXAgdG8gcGxvdC5hY2YgZnVuY3Rp b24uIEl0IGFsbG93cyB0bwpjdXN0b21pemUgdGhlIHRpdGxlcy4gTm93IG9uZSBjYW4gZXZlbiBw YXNzIG1haW4uc2VwIHZhbHVlIGNvbnRhaW5pbmcKJ1xuJywgc28gdHdvIHBhcnRzIG9mIHRoZSBj YXB0aW9uIGNvbWUgb24gZGlmZmVyZW50IGxpbmVzLiBUaGUgZGVmYXVsdAp2YWx1ZSBwcmVzZXJ2 ZXMgdGhlIG9yaWdpbmFsIGJlaGF2aW9yLgoKMikgQ2hhbmdlcyBtYWluIHRpdGxlIGNhcHRpb25z IHBvc2l0aW9uaW5nIGJlaGF2aW9yLiBOb3cgdGhleSBhcmUKcG9zaXRpb25lZCBhdXRvbWF0aWNh bGx5LCB3aGljaCBlbnN1cmVzIG5pY2VseSBsb29raW5nIGNhcHRpb25zIHdoZW4KbWFpbi5zZXAg Y29udGFpbmluZyAnXG4nIGlzIHVzZWQuCgpBbmRyZXkgUGFyYW1vbm92CgotLXBsZWFzZSBkbyBu b3QgZWRpdCB0aGUgaW5mb3JtYXRpb24gYmVsb3ctLQoKVmVyc2lvbjoKIHBsYXRmb3JtID0gaTQ4 Ni1wYy1saW51eC1nbnUKIGFyY2ggPSBpNDg2CiBvcyA9IGxpbnV4LWdudQogc3lzdGVtID0gaTQ4 NiwgbGludXgtZ251CiBzdGF0dXMgPQogbWFqb3IgPSAyCiBtaW5vciA9IDcuMAogeWVhciA9IDIw MDgKIG1vbnRoID0gMDQKIGRheSA9IDIyCiBzdm4gcmV2ID0gNDU0MjQKIGxhbmd1YWdlID0gUgog dmVyc2lvbi5zdHJpbmcgPSBSIHZlcnNpb24gMi43LjAgKDIwMDgtMDQtMjIpCgpMb2NhbGU6CkxD X0NUWVBFPXJ1X1JVLlVURi04O0xDX05VTUVSSUM9QztMQ19USU1FPXJ1X1JVLlVURi04O0xDX0NP TExBVEU9cnVfUlUuVVRGLTg7TENfTU9ORVRBUlk9QztMQ19NRVNTQUdFUz1ydV9SVS5VVEYtODtM Q19QQVBFUj1ydV9SVS5VVEYtODtMQ19OQU1FPUM7TENfQUREUkVTUz1DO0xDX1RFTEVQSE9ORT1D O0xDX01FQVNVUkVNRU5UPXJ1X1JVLlVURi04O0xDX0lERU5USUZJQ0FUSU9OPUMKClNlYXJjaCBQ YXRoOgogLkdsb2JhbEVudiwgcGFja2FnZTpzdGF0cywgcGFja2FnZTpncmFwaGljcywgcGFja2Fn ZTpnckRldmljZXMsCnBhY2thZ2U6dXRpbHMsIHBhY2thZ2U6ZGF0YXNldHMsIHBhY2thZ2U6bWV0 aG9kcywgQXV0b2xvYWRzLApwYWNrYWdlOmJhc2UK --=_Part_12871_19030521.1212173232092 Content-Type: text/x-diff; name=plot.acf.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fgv4g1yt0 Content-Disposition: attachment; filename=plot.acf.patch ZGlmZiAtLXJlY3Vyc2l2ZSAtLWNvbnRleHQgci1iYXNlLTIuNy4wL3NyYy9saWJyYXJ5L3N0YXRz L21hbi9wbG90LmFjZi5SZCByLWJhc2UtMi43LjAtYWNmLnBhdGNoL3NyYy9saWJyYXJ5L3N0YXRz L21hbi9wbG90LmFjZi5SZAoqKiogci1iYXNlLTIuNy4wL3NyYy9saWJyYXJ5L3N0YXRzL21hbi9w bG90LmFjZi5SZAkyMDA4LTAxLTMwIDEzOjI1OjA4LjAwMDAwMDAwMCArMDMwMAotLS0gci1iYXNl LTIuNy4wLWFjZi5wYXRjaC9zcmMvbGlicmFyeS9zdGF0cy9tYW4vcGxvdC5hY2YuUmQJMjAwOC0w NS0zMCAyMTowMDoyMy4wMDAwMDAwMDAgKzA0MDAKKioqKioqKioqKioqKioqCioqKiAxMSwxNyAq KioqCiAgfQogIFx1c2FnZXsKICBcbWV0aG9ke3Bsb3R9e2FjZn0oeCwgY2kgPSAwLjk1LCB0eXBl ID0gImgiLCB4bGFiID0gIkxhZyIsIHlsYWIgPSBOVUxMLAohICAgICAgeWxpbSA9IE5VTEwsIG1h aW4gPSBOVUxMLAogICAgICAgY2kuY29sID0gImJsdWUiLCBjaS50eXBlID0gYygid2hpdGUiLCAi bWEiKSwKICAgICAgIG1heC5tZnJvdyA9IDYsIGFzayA9IE5wZ3MgPiAxICYmIGRldi5pbnRlcmFj dGl2ZSgpLAogICAgICAgbWFyID0gaWYobnNlciA+IDIpIGMoMywyLDIsMC44KSBlbHNlIHBhcigi bWFyIiksCi0tLSAxMSwxNyAtLS0tCiAgfQogIFx1c2FnZXsKICBcbWV0aG9ke3Bsb3R9e2FjZn0o eCwgY2kgPSAwLjk1LCB0eXBlID0gImgiLCB4bGFiID0gIkxhZyIsIHlsYWIgPSBOVUxMLAohICAg ICAgeWxpbSA9IE5VTEwsIG1haW4gPSBOVUxMLCBtYWluLnNlcCA9ICIgJiAiLAogICAgICAgY2ku Y29sID0gImJsdWUiLCBjaS50eXBlID0gYygid2hpdGUiLCAibWEiKSwKICAgICAgIG1heC5tZnJv dyA9IDYsIGFzayA9IE5wZ3MgPiAxICYmIGRldi5pbnRlcmFjdGl2ZSgpLAogICAgICAgbWFyID0g aWYobnNlciA+IDIpIGMoMywyLDIsMC44KSBlbHNlIHBhcigibWFyIiksCioqKioqKioqKioqKioq KgoqKiogMzMsMzggKioqKgotLS0gMzMsMzkgLS0tLQogICAgXGl0ZW17eWxhYn17dGhlIHkgbGFi ZWwgb2YgdGhlIHBsb3QufQogICAgXGl0ZW17eWxpbX17bnVtZXJpYyBvZiBsZW5ndGggMiBnaXZp bmcgdGhlIHkgbGltaXRzIGZvciB0aGUgcGxvdC59CiAgICBcaXRlbXttYWlufXtvdmVyYWxsIHRp dGxlIGZvciB0aGUgcGxvdC59CisgICBcaXRlbXttYWluLnNlcH17dGhlIHNlcGFyYXRvciBpbiB0 aXRsZXMgb2YgY3Jvc3MtY29ycmVsYXRpb24gcGxvdHMufQogICAgXGl0ZW17Y2kuY29sfXtjb2xv dXIgdG8gcGxvdCB0aGUgY29uZmlkZW5jZSBpbnRlcnZhbCBsaW5lcy59CiAgICBcaXRlbXtjaS50 eXBlfXtzaG91bGQgdGhlIGNvbmZpZGVuY2UgbGltaXRzIGFzc3VtZSBhIHdoaXRlIG5vaXNlCiAg ICAgIGlucHV0IG9yIGZvciBsYWcgXGVxbntrfSBhbiBNQShcZXFue2stMX0pIGlucHV0P30K0KLQ vtC70YzQutC+INCyIHItYmFzZS0yLjcuMC1hY2YucGF0Y2gvc3JjL2xpYnJhcnkvc3RhdHMvbWFu OiBwbG90LmFjZi5SZH4KZGlmZiAtLXJlY3Vyc2l2ZSAtLWNvbnRleHQgci1iYXNlLTIuNy4wL3Ny Yy9saWJyYXJ5L3N0YXRzL1IvYWNmLlIgci1iYXNlLTIuNy4wLWFjZi5wYXRjaC9zcmMvbGlicmFy eS9zdGF0cy9SL2FjZi5SCioqKiByLWJhc2UtMi43LjAvc3JjL2xpYnJhcnkv
Re: [Rd] R-2.8.0 : get platform device with get(getOption("device"))
On Fri, 9 May 2008, Paul Roebuck wrote:
> On Thu, 8 May 2008, Peter Dalgaard wrote:
>
> > >> [SNIP Ripley conversation]
> >
> > oThe "device" option now is a function in some standard setups.
> > Consequentially, get(getOption("device")) will fail; programmers should
> > usually use dev.new() instead. (Assuming that the device is a character
> > string has been incorrect since 2.5.0.)
>
> Prof Brian Ripley noted [in another recent message] that
> it was also wrong to assume ANY arguments for dev.new
> method. If we are only concerned with interactive screen
> devices (i.e., x11, windows, quartz), would it be safe to
> come up with a method that can take basic dimension arguments
> (width & height)? Suggestions for an R-Core approved method
> of doing so?
>
> We use this functionality every day for creating multiple
> onscreen windows with specified dimensions.
Prof. Ripley replied to original note but not to my main
concern. Are there problems with this alternate approach
to creating new interactive devices (R-2.8+)?
Comments/Suggestions appreciated.
##--
## Create new interactive device. Arguments must be named.
intdev.new <- function(...) {
dev <- getOption("device")
if (is.character(dev)) {
if (exists(dev, .GlobalEnv))
dev <- get(dev, .GlobalEnv)
else if (exists(dev, asNamespace("grDevices")))
dev <- get(dev, asNamespace("grDevices"))
else {
stop(gettextf("device '%s' not found", dev),
domain = NA)
}
}
if (!is.function(dev)) {
stop("invalid setting for 'getOption(\"device\")'")
} else if (!dev.interactive(TRUE)) {
stop("device must be interactive")
}
arglist <- as.list(formals(dev))
extras <- match.call(expand.dots=FALSE)$...
if (length(extras) > 0) {
matched <- !is.na(match(names(extras), names(arglist)))
for (a in names(extras)[matched]) {
arglist[[a]] <- extras[[a]]
extras[[a]] <- NULL
}
if (length(extras) > 0) {
stop(sprintf("unnamed argument(s) not allowed: %s",
paste(extras, collapse=", ")))
}
if (any(!matched)) {
warning(sprintf("arguments ignored: %s",
paste(names(extras[!matched]),
collapse=", ")))
}
}
do.call(dev, arglist)
}
## Create interactive device using common arguments
R> intdev.new(width=5, height=5, title="Test")
TIA
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re quest: Documentation of formulae
Hi Mike, >> I was at a loss to understand the use of "/" until I looked in "An >> Introduction [!] to R," >> where I found the explanation. I am not with you on the [!], because the information is basically where you are "complaining" that it isn't, viz in your face --- i.e. in the introductory document ---, but the operator surely deserves a mention in ?formula. So on that score I agree with you. Best, Mark. Mike Prager wrote: > > In working through material on p.272 of MASS (4th ed.), I came > across the following model formula: > > pet1.lm <- lm(Y ~ No/EP - 1, Petrol) > > I was at a loss to understand the use of "/" until I looked in > "An Introduction [!] to R," where I found the explanation. > > My request is that more complete material on model formulae be > lifted from "Introduction to R" (or elsewhere) and put into the > main online help files. There are other useful notations that > may not be well known. Since formulae are not limited to any > particular function, perhaps an entry could be made under > "Formula". > > More justification: > > The help for "lm" does not explain this notation, nor did I find > a cross-reference to anything useful there. The R Reference > Manual seems to explain functions only. The R Language > Definition has no index entry for "formula" or "model formulae". > > Looking to print, neither the section on "model formula" on p.56 > of MASS nor the section surrounding the above example explains > the notation, nor could I find it in Dalgaard's book, nor in > Maindonald and Braun. > > This seems too nice a feature to keep hidden in plain sight. > > -- > Mike Prager, NOAA, Beaufort, NC > * Opinions expressed are personal and not represented otherwise. > * Any use of tradenames does not constitute a NOAA endorsement. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- View this message in context: http://www.nabble.com/Request%3A-Documentation-of-formulae-tp17567491p17568035.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
