Re: UI/UX implementation for suggestions

[Sudeepam Pandey]

On 28 Apr 2018 2:11 a.m., "Rik" <address@hidden> wrote:

On 04/27/2018 12:52 PM, Sudeepam Pandey wrote:

On Sat, Apr 28, 2018 at 12:25 AM, Rik <address@hidden> wrote:

On 04/27/2018 10:54 AM, Sudeepam Pandey wrote:
> > > Second, I think you need to spend some time up front thinking about the user interface (UI) and user experience (UX). Unfortunately, this is an area where there will be a lot of opinions. Nevertheless, you eventually need to have user's like how the feature is presented, or they will disable it and it will eventually atrophy and be removed from Octave. > > > How about I make something just like Nick suggested first? We can implement something like a simple pop-up for now and make it visible on the default branch (or maybe, only in my public clone, whatever seems better). The users can then try it for themselves and suggest UI improvements. The primary objective for now can be to just implement the 'how the feature presents itself to the user part'. > I believe that the starting point would probably be the error function? More specifically, the error message "error: <misspelling> undefined near..." Wouldn't the occurrence of this error message suggest that the user has misspelled? > > > Here are some questions to help motivate discussion. > > 1) Should keywords be included? The script I sent earlier was only for functions, but I personally would like a typo like "fndfunction" corrected to "endfunction" > > > Probably very short keywords like for and if should be excluded. Others can be included but again, it depends on whether we are able to easily list all of them up.
That was my suggestion.  Just add iskeyword() to the script I previously sent to get a list of keywords (easy).

Will do.

> > 2) Should user variables be included? If I define a variable "myvar" and then type "myver", what should happen? > > > Probably not, because that would probably require indexing the users script, either at the startup or at periodic intervals of time. That may slow some machines down. >
Okay.  Don't do variable suggestions at this time.

Understood.

> 3) Should internal functions ever be offered as suggestions? Internal functions start with the prefix "__". They are not meant to be called directly, so is there any reason to make them a suggestion? If I type "betaind", I should be reminded that I probably want "betainc", but I don't think I should be offered the choice "__betainc__" > > > Kindly excuse me for it but its the first time I have heard about 'internal functions'. Based on how you have described them and how I have understood it, I'd say that they probably should not be included. We defined the command line suggestion feature to be a feature that suggest corrections to 'typographic' errors. If the function will not be called directly, it probably will never be typed into the command line? Misspelling of such a function probably doesn't require a correction suggestion.
That is my vote as well.  That means you need to remove all function names which start with "__" from the automatically generated list.

Will do.

> > 4) What about deprecated functions? Should they ever be offered as a suggestion? You could just remove them from the suggestion list, or maybe you want to go a step further and recommend their replacement? > > > I'm sorry I don't know what deprecated functions in Octave are. Can you please tell me?
Deprecated functions are in the directory scripts/deprecated.  These are functions which are scheduled for removal from Octave within the next two release cycles.  As an example, if I look in the development branch I find desktop.m.  Inside the file, the documentation says

## @code{desktop} is deprecated and will be removed in Octave version 6.
## Use @code{isguirunning} for the equivalent functionality.

So, one course of action is to treat deprecated functions like any other function and provide a suggestion if someone types "desktip".  A second course is to remove deprecated functions from the suggestion list so "desktip" generates no alternatives.  Finally, you could suggest that "desktip" be replaced with "isguirunning".

To include or not to include these functions may depend on the number of deprecated functions. If their inclusion dosen't increase the complexity of our program by a significant amount, then we can include them. Otherwise we should ignore them.

Generally the list is quite small, < 10 functions.

I forgot another category of typo which might be useful which would be graphics properties.

5) What about graphics properties like "BusyAction" or "ColorMap"?  Should we offer suggestions for these?

I haven't worked with graphic properties before (or I may have but may not be aware of this terminology). Is octave able to catch errors related to invalid graphic properties? If Octave is able to do so, and the user types these in the command line, then they can be included.

Octave does generate an error for unrecognized graphic properties.  See this session

octave:1> h = gca
h = -18.142
octave:2> set (h, 'colormip', [1 1 1])
error: set: unknown axes property colormip

--Rik

Then we can include these two as well.