[Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()

[Peter Ruckdeschel]

Dear Seth,

thank you very much for your helpful comments:

>I had a quick look and for what it's worth, a few comments...
>
>* Seems a bit more code than I would expect.

Arguable, yes...

>  I think you have some use cases that I don't have ;-).

hopefully I'm not the only one to have these cases :-)

>  In terms of general use, I would suggest making a stab at a
>  simplified version.

I have tried to do something in that direction:

* files startUpMessage.R / StartupUtilities.Rd now gather the code
  addressing a more general audience; (?"startupmsg")

* files illustration.R / myStartupUtilities.Rd
  [ with mySMHandler, mystartupMessage, buildStartupMessage ]
   (?"mySMHandler") may be thought of an illustration of the concept
  (and hence should not enter general packages, I suppose)

the revised code is available again under

   http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.2.tar.gz

>  For example, what's the difference between startupMessage and
>  startupVersionMessage; are both needed?

I guessed so: the idea is to have more than one type of
StartupMessage, and suppressing should be done according to the type;

I have rethought this now: instead of two (or more) subclasses
of StartupMessage, I now have endowed class StartupMessage with an
extra slot type, which currently is supposed to take one of the tree
values

  + "version":     version and title information from the DESCRIPTION file
  + "notabene":   "nota bene"s on the package to be given at
                   this prominent place
  + "information": (starting) pointers for more information on the
                   package:
                   -howto call the package help file,
                   -howto inspect the NEWS file,
                   -additional manuals/vignettes
                   -URLs

(but the code already supports arbitrarily many type values)

>  And linestarter?

I agree: this should better be dealt with in a more general/flexible way
by allowing  + the developper using 'startupMessages'
               to use his own SMHandler (for /S/tartup/M/essage/Handler/)
               as illustrated in 'mystartupMessages'
             + the user of a package with 'startupMessages'
               to specify a suitable custom restart
               (see examples in ?"startupmsg")
               --- is achieved using your code example

>* Consider adding a customizable restart.  As it stands, startupmsg
>  doesn't give a user more control than message().

Now it does; I admit, I should have integrated your proposed elegant
code right from the beginning.

> That is, you can either muffle the messages or not.  If I want to write
> them to a file or prefix them with funny characters, doing so by grabbing
> hold of the message before it is emitted via the restart seems like a
> nice approach (although one could argue for a more general system
> logging system that probably would not need the fancy condition
> system use).

Thank you again
Peter