Re: Modifications to error handling for the command suggestion feature

[Sudeepam Pandey]

On Sun, May 20, 2018 at 8:56 AM, Rik <address@hidden> wrote:

On 05/19/2018 02:12 PM, Sudeepam Pandey wrote:

Providing a list of suggestions and then returning to the CLI is going to be easier then changing the parser--which has already gone down an error path--to accept new input, backup, and re-parse the new command.  The latter can be done, but for the moment I would concentrate on just offering the user some suggestions.

You did correctly find the code in pt-id.cc to modify.  The complete routine is

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    maybe_missing_function_hook (name ());

    if (l == -1 && c == -1)
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined", name ().c_str ());
    else
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined near line %d column %d",
                     name ().c_str (), l, c);
  }

What you want to do is print out an error message first, then call maybe_missing_function_hook, and then return to the prompt.  You can't use error_with_id because it is based on exceptions and will return to the prompt as soon as it is done.  However, you can print the warning to stderr, which is what the error() function is doing anyways.  Try this

Our primary need is not to print the error message first, but to make sure that an error message for the mistake made in the last command does not occur after the user has executed the correct command. 

If the command is correct, then there is no undefined error.  If the command is not correct, you can offer a suggestion, but there is no way for the user to correct the command and have it execute.  They need to return to the prompt and enter the correct command.  That was my point about not being able to back up the parser and have it re-execute on the suggestion that you supply in the function called by missing_function_hook.

--Rik

Ohh I understand. So what should we aim for? Display suggestions only or make a pop-up like feature? I've also come across another reason about why providing an execution option wouldn't be the best idea... would like to explain it with an example.

Say a user wants to generate a sine wave in octave with a frequency of 5Hz. They would type something like...

>> x = sin (2*pi*5*t) # t is a previously declared variable that contains time samples.

now if the user misspells and types...say...

>> x = sine (2*pi*5*t)

The suggestion feature would output something like...

----------------------------------------
Did you mean...
sin

error: 'sine' undefined near line 1 column 1
-----------------------------------------

This is because 'sine' is the part that the parser dosen't recognize and so 'sine' is what is corrected to 'sin'

This sin cannot be executed directly without the appropriate arguments and I don't think that we have a way to pass down the entire _expression_ to the pop-up. A better way here to correct the spelling would be to press the upward arrow key and change sine to sin.

So this is another reason why I am starting to believe that displaying a text only suggestion is the best option because octave already provides a reasonably easy way to edit and change commands. Doing this would also save us the task of changing the error handling.