Warning function interface

[John W. Eaton]

At the meeting last week, we discussed allowing warning states to be
local to a function, similar to how preference settings like
"debug_on_error" (for example) can be local:

   -- Built-in Function: VAL = debug_on_error ()
   -- Built-in Function: OLD_VAL = debug_on_error (NEW_VAL)
   -- Built-in Function:  debug_on_error (NEW_VAL, "local")
       Query or set the internal variable that controls whether Octave
       will try to enter the debugger when an error is encountered.  This
       will also inhibit printing of the normal traceback message (you
       will only see the top-level error message).

       When called from inside a function with the "local" option, the
       variable is changed locally for the function and any subroutines
       it calls.  The original variable value is restored when exiting
       the function.

I asked Juan Pablo to think about what the syntax should be since
warning settings are somewhat different from other internal preference
settings.  His proposal is

  Ok, reading matlab
  (http://www.mathworks.ch/help/techdoc/ref/warning.html) and octave
  documentation for warning the best way to implement the keyword
  "local" (which extends matlab functionality) is to add a behavior
  dependent on the reserved words for the first argument.
  The current behavior is

  -- Built-in Function:  warning ("on", ID)
  -- Built-in Function:  warning ("off", ID)
  -- Built-in Function:  warning ("query", ID)
  -- Built-in Function:  warning ("error", ID)

  I think adding the cases

  -- Built-in Function:  warning (state, ID, "local")

  where state is any of {"on","off","query","error"}.

  This gets messy but the argument checking should go

  If state is in {"on","off","query","error"} and nargin == 3
  then make warning local.

  Alternatively "local" could work only with "on","off" and "error".
  Otherwise "query" should return an extra field telling whether the
  warning is local or not.

  Let me know if I can be of any help.


I think this seems like a reasonable addition.  Does anyone see a
problem with this proposal?

jwe