Re: help as m-files

[John W. Eaton]

On 29-Oct-2008, Søren Hauberg wrote:

| ons, 29 10 2008 kl. 17:52 -0400, skrev John W. Eaton:
| > | Yes, I would prefer that. However, I'm not sure if it is a good change.
| > | The current code is really simple as it just calls a macro. So, this
| > | work only makes sense if we can remove all internal variables.
| > 
| > I'm confused now.  What current code is that?
| 
| Sorry about that. Currently the code to handle the 'info_file' variable
| is handled with the following code (my changeset doesn't change this,
| because I wasn't sure about the consequences)
| 
| DEFUN (info_file, args, nargout,
|   "-*- texinfo -*-\n\
| @deftypefn {Built-in Function} address@hidden =} info_file ()\n\
| @deftypefnx {Built-in Function} address@hidden =} info_file
| (@var{new_val})\n\
| Query or set the internal variable that specifies the name of the\n\
| Octave info file.  The default value is\n\
| @code{\"@var{octave-home}/info/octave.info\"}, in\n\
| which @var{octave-home} is the directory where all of Octave is
| installed.\n\
| @seealso{info_program, doc, help, makeinfo_program}\n\
| @end deftypefn")
| {
|   return SET_NONEMPTY_INTERNAL_STRING_VARIABLE (info_file);
| }
| 
| That seems quite simple to me. If you need to do a lot of work to move
| this to an m-file, then I'm just not sure if it's worth the effort. But
| hey, I haven't looked into the details, so I just might be missing the
| obvious.

OK, I see your point.  Let's leave these alone for now.

Thanks,

jwe