[Rd] ?setGeneric garbled (PR#14153)

[murdoch at stats.uwo.ca]

On 19/12/2009 8:56 AM, Martin Maechler wrote:
>>>>>> "DM" == Duncan Murdoch <murdoch at 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 <mtmorgan at fhcrc.org>
>     >>>>>>>> on Fri, 18 Dec 2009 07:40:13 -0800 writes:
>     >>> > Martin Maechler wrote:
>     >>> >>>>>>> Martin Morgan <mtmorgan at 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 <ross at 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.  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