octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: option for enabling/disabling auto-suggest feature


From: Sudeepam Pandey
Subject: Re: option for enabling/disabling auto-suggest feature
Date: Wed, 2 May 2018 23:42:27 +0530



On Wed, May 2, 2018 at 9:34 PM, Rik <address@hidden> wrote:
On 05/02/2018 05:55 AM, Sudeepam Pandey wrote:


Understood Doug.

There is one last thing left for me to figure out kindly help me with the same.

Like I sad before...I edited the __unimplemented__.m script a little so that, whenever octave fails to find an identifier among the unimplemented functions list as well, it calls my __suggestion__.m script, and this has worked nicely to produce a "Did you mean?" suggestion in the Octave command window in both GUI and CLI.

There are a two things that still need to be taken care of..

1) First of all, we absolutely need a on/off switch for this feature. However, __suggestion__.m will be designed as an internal function (called when an identifier is not found in the unimplemented functions list) so users cannot directly call this function.
So to design a command which can act as a switch for this feature, we can write a m script (say flag.m) which is callable from the command window with a flag value and which would save the desired flag value (indicating on/off) in a .mat file in the "..octave/scripts/help" directory (where __suggestions__.m would reside). The __suggestions__.m script would load this value as soon as it is called and act accordingly. This way the user setting will be saved and will remain protected unless they modify it themselves.
I however, don't understand what files do I have to tweak so that the parser learns to identify this function (flag.m) as a new function of octave, callable from the command window. Also, if we went along with this, what path should I set inside the flag.m file so that the .mat file in "..octave/scripts/help" directory gets updated successfully? considering that the path BEFORE "../octave/scripts/help" would be different for each user, depending on where they have saved their copy of octave.
I understand that I may have said somethings incorrectly here, or that my thinking may be wrong at some places (for example, maybe we have to have a flag.cc file and not a flag.m file) but this approach is probably how a very good on/off feature could be made. Help and suggestions would be appreciated.

I would suggest using getpref()/setpref() for the time being.  For the namespace, use "Octave".  For the actual name of the preference, maybe something like "autosuggest".  In this case, your code can use getpref to check whether the value is boolean true before continuing.  For the time being you don't even need to write an m-file to enable/disable the option.  You can just use setpref directly.  Later on, you could wrap setpref() in an m-file to give it a nice interface.

Here is a demo I made just now... It is able to do the job of a on/off feature. The initial try/catch block is for the first time when the preference 'autosuggestion' will not be present in the group 'Octave'. Later on, the user can turn the feature on/off using setpref();

-------------------------------------------------------------------------------------------------------------------------------------

function txt = __suggestions__(fcn)

  try
    getpref ("Octave", "autosuggestion");
  catch err
    if (strcmpi (err.message, "getpref: preference autosuggest does not exist in GROUP Octave"))
      addpref ("Octave", "autosuggestion", true);
    endif
  end

  pref = getpref ("Octave", "autosuggestion");
  if (pref == false)
    disp ("Disabled");
  elseif (pref == true)
    disp ("Did you mean any of the following...");
  endif
 
endfunction;

----------------------------------------------------------------------------------------------------------------------------------------

Note: It is a sample code, it may not strictly adhere to the Octave style of coding.


2) Another thing that bothers me is the absence of missing_property_hook() function...the approach that we have discussed does not work when we make a typo while typing a graphic/line property etc.. We can choose to add a missing_property_hook() function but this would have additional challenges. Examples are...
   a) How do we do it? What files do we tweak?
The file to inspect is libinterp/corefcn/graphics.cc.

grep -n error graphics.cc | grep property

74:  error ("set: invalid value for %s property", pname.c_str ());
104:    error ("%s: unknown %s property %s",
116:      error ("%s: ambiguous %s property name %s; possible matches:\n\n%s",
1312:        error (R"(invalid value for color property "%s")",
1346:              error (e, R"(invalid value for color property "%s" (value = %s))",
1356:        error (R"(invalid value for color property "%s")",
1369:    error (R"(invalid value for color property "%s")",
1384:        error (R"(invalid value for double_radio property "%s")",
1411:    error (R"(invalid value for double_radio property "%s")",
1657:        error (R"(set: invalid graphics handle (= %g) for property "%s")",
1660:        error (R"(set: invalid graphics object type for property "%s")",
1851:        error ("addproperty: missing possible values for radio property");
1913:        error ("addproperty: unsupported type for dynamic property (= %s)",
1937:        error ("addproperty: invalid object type (= %s)",
2194:            error ("invalid %s property '%s'", pfx.c_str (), pname.c_str ());
2219:    error ("invalid default property specification");
3069:              error (e, "error setting default property %s", pname.c_str ());
3098:    error (R"(get: unknown property "%s")", pname.c_str ());
3141:    error (R"(set: unknown property "%s")", pname.c_str ());
3157:    error (R"(get_property: unknown property "%s")", pname.c_str ());
5031:      error ("set: expecting text graphics object or character string for %s property, found %s",
10885:            error ("set: unknown property");
11115:            error ("__go_%s__: missing value for parent property",
11988:    error ("addproperty: invalid graphics object (= %g)", h);
11995:    error ("addproperty: a '%s' property already exists in the graphics object",

Only the error statements which deal with an unknown property would need modification.  I think the idea would be to intercept the error call about an unknown property.  At each point you would first check for missing_property_hook().  If it was empty then error out in the same way as before.  Otherwise, call the function provided in missing property hook and then call error() with whatever text was returned from the suggestions.  Note, that this would just give you suggestions, it would not necessarily be possible to print a menu and have the user decide which one they wanted to change the text to.

   b) If we finally make it, what does the parser prioritize when it doesn't recognize an identifier? missing_function_hook or the missing_property_hook?

If you implement it the way I suggested then the two functions are at different levels of parsing and missing_function_hook would take precedence over missing_property_hook.

I understand. There are a few doubts however...

1) Will this file, libinterp/corefcn/graphics.cc cover all the major properties (figure, line, axis, etc...)?
2) Can you tell me where I can find missing_function_hook() so that I could make missing_property_hook() similar to that?



...and maybe more challenges when we start thinking how?

I really would like to include properties as well but I'm not sure if they could be done right now. Can anyone help with this?

--P Sudeepam



reply via email to

[Prev in Thread] Current Thread [Next in Thread]