I confirm that R 2.10.1 fixes the problem under ESS 5.7.1 on Windows XP.
See below for one more comment.
On Sat, 2009-12-19 at 10:03 -0500, Duncan Murdoch wrote:
> On 19/12/2009 8:56 AM, Martin Maechler wrote:
> >>>>>> "DM" == Duncan Murdoch <murd...@stats.uwo.ca>
> >>>>>> on Fri, 18 Dec 2009 15:03:26 -0500 writes:
> >
> > DM> On 18/12/2009 1:15 PM, Duncan Murdoch wrote:
> > >> On 18/12/2009 12:54 PM, Martin Maechler wrote:
> > >>>>>>>> Martin Morgan <mtmor...@fhcrc.org>
> > >>>>>>>> on Fri, 18 Dec 2009 07:40:13 -0800 writes:
> > >>> > Martin Maechler wrote:
> > >>> >>>>>>> Martin Morgan <mtmor...@fhcrc.org>
> > >>> >>>>>>> on Thu, 17 Dec 2009 09:54:54 -0800 writes:
> > >>> >>
> > >>> >> > Ross Boylan wrote:
> > >>> >> >> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote:
> > >>> >> >>>>>>>> Ross Boylan <r...@biostat.ucsf.edu>
> > >>> >> >>>>>>>> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes:
> > >>> >> >>> > Full_Name: Ross Boylan
> > >>> >> >>> > Version: 2.10.0
> > >>> >> >>> > OS: Windows XP
> > >>> >> >>> > Submission from: (NULL) (198.144.201.14)
> > >>> >>
> > >>>
> > >>> >> >>> > Some of the help for setGeneric seems to have been
> > garbled. In the section
> > >>> >> >>> > "Basic Use", 5th paragraph (where the example counts as a
> > single line 3rd
> > >>> >> >>> > paragraph) it says
> > >>> >> >>> > <quote>
> > >>> >> >>> > Note that calling 'setGeneric()' in this form is not
> > strictly
> > >>> >> >>> > necessary before calling 'setMethod()' for the same
> > function. If
> > >>> >> >>> > the function specified in the call to 'setMethod' is not
> > generic,
> > >>> >> >>> > 'setMethod' will execute the call to 'setGeneric' itself.
> > >>> >> >>> > Declaring explicitly that you want the function to be
> > generic can
> > >>> >> >>> > be considered better programming style; the only
> > difference in the
> > >>> >> >>> > result, however, is that not doing so produces a You
> > cannot (and
> > >>> >> >>> > never need to) create an explicit generic version of the
> > primitive
> > >>> >> >>> > functions in the base package.
> > >>> >> >>> > <quote>
> > >>> >> >>>
> > >>> >> >>> > The stuff after the semi-colon of the final sentence is
> > garbled, or at least
> > >>> >> >>> > unparseable by me. Probably something got deleted by
> > mistake.
> > >>> >> >>>
> > >>> >> >>
> > >>> >> >> The last sentence of this paragraph is also garbled:
> > >>> >> >> <quote>
> > >>> >> >> The description above is the effect when the package that
> > owns the
> > >>> >> >> non-generic function has not created an implicit generic
> > version.
> > >>> >> >> Otherwise, it is this implicit generic function that is
> > us_same_
> > >>> >> >> version of the generic function will be created each time.
> > >>> >> >> </quote>
> > >>> >>
> > >>> >> > Off-list, I guess both of these paragraphs have very long
> > lines in the
> > >>> >> > source; maybe your emacs is truncating lines instead of
> > wrapping, or
> > >>> >> > something similar?
> > >>> >>
> > >>> >> Thank you, Martin, but no, we never have very long lines in the
> > >>> >> R sources (and *.Rd files belong to the sources),
> > >>> >> and then translation of the *.Rd file to a "data base" of
> > >>> >> text-help entries should keep newlines.
> > >>>
> > >>> > I meant that they _are_ very long in the source. Martin
> > >>>
> > >>> Oh dear, yes indeed, you are right!
> > >>>
> > >>> So, astonishing as that may be, indeed for the 'text' version of
> > >>> help, it seems that ... under some circumstances ...
> > >>> the (NAMESPACE-hidden) method
> > >>> utils:::print.help_files_with_topic()
> > >>>
> > >>> which ends up calling file.show() :
> > >>>
> > >>> if (file.exists(paste(RdDB, "rdx", sep = "."))) {
> > >>> temp <- tools::Rd2txt(tools:::fetchRdDB(RdDB,
> > >>> basename(file)), out = tempfile("Rtxt"), package = pkgname)
> > >>> file.show(temp, title = gettextf("R Help on '%s'",
> > >>> topic), delete.file = TRUE)
> > >>> }
> > >>>
> > >>>
> > >>> *is* still influenced by the original *.Rd file's (lack) of new
> > >>> lines, somewhat astonishingly to me.
> > >>>
> > >>> Even more, I cannot understand that other people do not see the
> > >>> same phenomenon (though maybe they would if they cared to
> > notice...),
> > >>> and also that you only get the "garbling" problem with ESS, and
> > >>> only for R version 2.10, but not 2.8.
> > >>> Did our 'Rd2txt()' change here on purpose?
> > >>>
> > >>
> > >> I seem to recall fixing a bug in the line wrapping code, but I can't
> > >> spot it in a quick glance over the log. Maybe I forgot to commit
> > the
> > >> fix? I can't look into this now, but I'll follow up later.
> >
> > DM> The patch I recalled did get committed on November 8, with this
> > NEWS entry:
> >
> >
> > DM> o Text help rendering did not handle very long input lines
> > DM> properly.
> >
> >
> > DM> So it made it into 2.10.1. Do you still see the problem there? I
> > don't
> > DM> see it in text help for setGeneric in the Windows gui.
> >
> > DM> Duncan Murdoch
> >
> > I think it was never a problem in the GUI,
> > however when using ESS.
>
> It was simply a problem of Rd2txt in 2.10.0, and appeared wherever that
> was used: in the GUI, in Rterm, whatever.
It did not appear for me when using the standard R GUI launched from the
icon for R on the desktop.
> The bug report was about an
> obsolete version.
>
> Duncan Murdoch
>
> >
> > For some reason, I did overlook that Ross was talking about
> > Windows. I had never checked it on Windows,
> > but did now {using our Windows terminal server}.
> >
> > Indeed: R 2.10.0 with ESS shows the problem Ross found
> > R 2.10.1 with ESS *NO LONGER* shows the problem.
> >
> > --> I'm CC'ing R-bugs, as this bug report
> > ... an R bug after all ..
> > can be closed.
> >
> > Thanks to all helpers!
> > Martin Maechler, ETH Zurich
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
