[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Updated model of "Help" Command
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] Updated model of "Help" Command |
Date: |
Tue, 8 Jul 2014 00:16:48 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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