Re: default ~/.octaverc template

[Keith Goodman]

That's perfect! (The only downside I can see is that the ~/.octaverc
template will be very long.)

Should the ~/.octaverc file be created when Octave is built or should
it be created when Octave is run for the first time? The former is
faster for the user (and it won't crash) but the latter can update the
automated descriptions if a user changes the help documentation. Wait,
that's not true because the ~/.octaverc file is only created the first
time a user runs Octave. My guess is that the file should be
constructed when Octave is built. But an automated dump_prefs
functions will be even more useful than an ~/.octaverc template so I
take that back.

On 4/29/05, John W. Eaton <address@hidden> wrote:
> On 29-Apr-2005, Keith Goodman wrote:
> 
> | Here's a revised proposal for an ~/.octaverc template to be installed
> | in a users home directory the first time they run Octave if an
> | ~/.octaverc file does not already exist.
> 
> Here is another possibility.  Instead of generating this by hand, how
> about writing a function that will dump a list of all the built-in
> variables along with their documentation, formatted in a manner
> suitable for use as a ~/.octaverc file.  That way, if the defaults
> change, or if the documentation changes, or if some variables are
> added or removed from Octave, we don't have to remember to edit the
> example file?  Everything would be commented out.  So instead of
> 
>   ## Turn off pagination.
>   ##
>   ## more off;
> 
> we would have
> 
>   ## -- Built-in Variable: page_screen_output
>   ##     If the value of `page_screen_output' is nonzero, all output
>   ##     intended for the screen that is longer than one page is sent
>   ##     through a pager.  This allows you to view one screenful at a time.
>   ##     Some pagers (such as `less'--see *Note Installation::) are also
>   ##     capable of moving backward on the output.  The default value is 1.
>   ##
>   ## page_screen_output = 1;
> 
> Note that there is already a function called dump_prefs that does part
> of this, but it is also hand-written, along with the comment
> 
>   ## XXX FIXME XXX -- it would be nice to be able to get the list of
>   ## built-in variables directly from Octave so that we wouldn't have to
>   ## remember to update it each time the list of preference variables
>   ## changes
> 
> I'm sure that the list of variables in dump_prefs is now out of date,
> so maybe it is time to do this job?
> 
> We will also need to fix the help function to return it's output
> instead of sending it to octave_stdout if nargout > 0 so we can
> capture the docstrings and write them to a file.
> 
> jwe
>