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

From: Peter Ruckdeschel <>
Date: Wed 19 Apr 2006 - 19:26:59 GMT

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:

the revised code is available again under

> 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
                   -howto call the package help file,
                   -howto inspect the NEWS file,
                   -additional manuals/vignettes

(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 mailing list Received on Thu Apr 20 05:43:29 2006

This archive was generated by hypermail 2.1.8 : Wed 19 Apr 2006 - 20:18:02 GMT