Re: [Rd] ?setGeneric garbled (PR#14153)

From: <maechler_at_stat.math.ethz.ch>
Date: Sat, 19 Dec 2009 15:01:37 +0100 (CET)


>>>>> "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.

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_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat 19 Dec 2009 - 14:05:56 GMT

This archive was generated by hypermail 2.2.0 : Sat 19 Dec 2009 - 20:01:11 GMT