Re: Updated model of "Help" Command

Hi Rishabh.

On Mon, Jul 07, 2014 at 01:55:25PM +0200, Rishabh Yadav wrote:
> But now I have another model which differs from previous one.
> Now,the manual of a plugin can be written in a separate file say
> manual_plugin.hlp and then the groff command can be exploited for document
> formatting and providing the formatted text to the user.

i think we should differentiate between 'short help' and 'extended
help/manual'. to me it makes sense to produce 'short help' from the
information already present within the CARDs. for example, the user
could get the name(s) of a device, see the port number and names and an
example instanciation (depending on OPT::language). this should not
depend on whether somebody has written a manual explicitly.

> In our case,whenever the call goes to help command,the manual page for the
> plugin can be provided in the interpreter by calling a function like
> *groff -man -Tascii ./manual_plugin.hlp | less*
> The manual pages for gnucap have to be written in a standard format that we
> can discuss and define later.

how about texinfo format, as Al proposed? a texinfo manual could then be
made accessible outside of gnucap (info, pdf, man, html, whatever) but
should in particulatly be provided as a plugin (using the help
dispatcher) to supplement the (interactive!) short help.

> All such manual pages for plugins will reside in a particular folder.It has
> few benefits.
> 1.-4. [..]

it seems 1-4 are still compatible with the idea suggested above. but in
addition,

5. a plugin may contain its own interactive help.

which i think is really important. the following looks useful to me, if
i get/send a plugin (say p.cc) from/to someone.

>load ./p.cc
loaded p
>help p
{ help text here }

cheers
felix