[rkward-devel] rkh file for utility functions

[Prasenjit Kapat]

Hi,

On Sat, Sep 25, 2010 at 6:52 AM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
> Hi,
>
> On Saturday 25 September 2010, Prasenjit Kapat wrote:
>> I've added a rk.list.plugins (...) to public.R, I hope it is not
>> adding a "new feature."
>
> well, it's sort of a new feature, but the important point is that it looks
> safe to add without breaking anything.
>
>> While documenting rk.call.plugin, I felt that
>> the user generally will have no idea of what goes as the first
>> argument ("plugin").
>
> True. And also, of course, the user generally will have no idea of what the
> available arguments are for a particular plugin.

Right. This is will be a more important limitation.

> Well, rk.call.plugin() is mostly a by-product of the "Run again" link, and the
> automated tests. I'm not sure whether there is a real use-case for it beyond
> that (and I've added some words of caution to the .Rd-file), but potentially it
> might be interested for scripting tutorial or similar purposes.

Actually in this respect, I felt, some of these functions can go in
internal*.R as well. We may want to document them (and other
functions) as part of internal*.R functions which will be helpful for
those users who want to take the next step: contribute: either plugins
/ docs / core C++ side etc... These doc / help files need not be
exposed to the "regular users."

If you prefer, I can add a pages/rkward_for_rkward_devs.rkh and move
these links there? Then, move these functions back into internal.R?

>> Is there any way to improve this? Right now, I am
>> just scanning the pluginmap files... Can the C++ side list all the
>> available plugins?
>
> Yes, and I've changed it to use that. However, the C++-side does not keep

Yeah, I always felt had to be a better solution than reading and
parsing the files from disk. I wanted to have some solution (albeit a
dumb one) before asking you ;)

> track of where the plugin was declared, so this feature is lost. Note that
> both versions of rk.list.plugins() also list plugins which are not really
> meant to be called from the top-level, i.e. including those designed for
> embedding, or context-sensitive plugins like the graphics export-plugin.

Yeah this kind of brings back the argument of moving these into
internal.R, or at least move the help links to a
rkward_for_rkward_devs.rkh page.

Regards,
-- 
Prasenjit