Re: UI/UX implementation for suggestions

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

Rik-4
On 04/27/2018 07:33 AM, [hidden email] wrote:
Subject:
Re: Proceeding with the GSoC Project
From:
Nicholas Jankowski [hidden email]
Date:
04/27/2018 06:20 AM
To:
Sudeepam Pandey [hidden email]
CC:
Nicholas Jankowski [hidden email], Doug Stewart [hidden email], octave-maintainers [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
multipart/alternative; boundary="001a114d73fa99cdf0056ad4603b"
Message:
1



On Fri, Apr 27, 2018, 08:43 Sudeepam Pandey <[hidden email]> wrote:


On Fri, Apr 27, 2018 at 5:05 PM, Nicholas Jankowski <[hidden email]> wrote:



It seems you have several separable programming tasks. These need to be blocked out and addressed independently. That includes and analysis of options and alternatives after a review of what's been done before by others.

 1 - implement a suggestion feature within octave, independent of algorithm, and a framework for connecting to it. I would consider this a near term objective, lest it become a last minute kludge. It would be testable with even the most trivial of suggestion algorithms 

2 - implement a suggestion algorithm for 'online' suggestions, that needs to be delay free to the user. It may make sense to have both high confidence and lower confidence a approaches to this, bit I'm not yet convinced you've researched to options including what's already been done.

3 - implement any offline suggestion algorithm components that will aid 2. This may or may not be separable from 2. If this requires maintainer action, that will need a reasonable framework.

4. Document. Especially if this will require later manual actions on each new octave release. updates

I am really sorry but I don't understand some of these things. Please clear these up for me.

1) What exactly do you mean by a suggestion feature "independent of an algorithm" and "testable with even the most trivial of suggestion algorithms"?

2) What do you mean by "online and offline suggestions"?


1 - how the feature presents itself to the user and hooks into octave is separate from what happens behind the scenes to generate the words to suggest.  

If we implemented a  pop-up dialog box where the user could select the intended command, that could be tested without having any neural network or nearest neighbor searching going on in the background. It could be tested with a simple 10 word look up table just to show that the functionality is correct. Later the actual suggestion feature should be some separate, independent function that is separately testable. But having it be independent will involve defining the interface to that piece such that any algorithm should be able to provide word suggestions to it. If a better algorithm comes along later, someone could implement it without having to change the code for actually hooking into octave.

Sudeepam,

For better or worse, you have a project which is generating a lot of interest.  First, I agree with the others that you should separate the implementation of a suggestion algorithm, from the interface to the user.  Logically, they are different and it allows a "divide and conquer" approach to engineering.  It also helps future proof the system.  If the actual suggestion algorithm is implemented through a stable API then as new techniques come along we can improve the quality of the suggestions without ever disturbing the user.

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.

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"
2) Should user variables be included?  If I define a variable "myvar" and then type "myver", what should happen?
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__"
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?
5) How are you going to offer alternatives and allow them to select an alternative?  Remember that Octave has both a CLI and a GUI so you may need two solutions.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

Sudeepam Pandey


On Fri, Apr 27, 2018 at 10:14 PM, Rik <[hidden email]> wrote:
On 04/27/2018 07:33 AM, [hidden email] wrote:
Subject:
Re: Proceeding with the GSoC Project
From:
Nicholas Jankowski [hidden email]
Date:
04/27/2018 06:20 AM
To:
Sudeepam Pandey [hidden email]
CC:
Nicholas Jankowski [hidden email], Doug Stewart [hidden email], octave-maintainers [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email] [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
multipart/alternative; boundary="001a114d73fa99cdf0056ad4603b"
Message:
1



On Fri, Apr 27, 2018, 08:43 Sudeepam Pandey <[hidden email]> wrote:


On Fri, Apr 27, 2018 at 5:05 PM, Nicholas Jankowski <[hidden email]> wrote:



It seems you have several separable programming tasks. These need to be blocked out and addressed independently. That includes and analysis of options and alternatives after a review of what's been done before by others.

 1 - implement a suggestion feature within octave, independent of algorithm, and a framework for connecting to it. I would consider this a near term objective, lest it become a last minute kludge. It would be testable with even the most trivial of suggestion algorithms 

2 - implement a suggestion algorithm for 'online' suggestions, that needs to be delay free to the user. It may make sense to have both high confidence and lower confidence a approaches to this, bit I'm not yet convinced you've researched to options including what's already been done.

3 - implement any offline suggestion algorithm components that will aid 2. This may or may not be separable from 2. If this requires maintainer action, that will need a reasonable framework.

4. Document. Especially if this will require later manual actions on each new octave release. updates

I am really sorry but I don't understand some of these things. Please clear these up for me.

1) What exactly do you mean by a suggestion feature "independent of an algorithm" and "testable with even the most trivial of suggestion algorithms"?

2) What do you mean by "online and offline suggestions"?


1 - how the feature presents itself to the user and hooks into octave is separate from what happens behind the scenes to generate the words to suggest.  

If we implemented a  pop-up dialog box where the user could select the intended command, that could be tested without having any neural network or nearest neighbor searching going on in the background. It could be tested with a simple 10 word look up table just to show that the functionality is correct. Later the actual suggestion feature should be some separate, independent function that is separately testable. But having it be independent will involve defining the interface to that piece such that any algorithm should be able to provide word suggestions to it. If a better algorithm comes along later, someone could implement it without having to change the code for actually hooking into octave.

Sudeepam,

For better or worse, you have a project which is generating a lot of interest.  First, I agree with the others that you should separate the implementation of a suggestion algorithm, from the interface to the user.  Logically, they are different and it allows a "divide and conquer" approach to engineering.  It also helps future proof the system.  If the actual suggestion algorithm is implemented through a stable API then as new techniques come along we can improve the quality of the suggestions without ever disturbing the user.

Even I agree with that. So this part is sorted I suppose. We'll proceed this way.

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.

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.

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.

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?
 
5) How are you going to offer alternatives and allow them to select an alternative?  Remember that Octave has both a CLI and a GUI so you may need two solutions.

Something to think about. GUI would probably be easy but CLI may be tricky. I'll figure it out when I start going through the code-base in detail. Can you tell me which directory/files handle the GUI and which ones handle the CLI?


--Rik

Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

nrjank
> GUI would probably be easy but CLI may be tricky

hmm.. I was thinking the opposite actually. Also, a CLI option would work in either case, whereas a GUI option would require a CLI option for --no-gui users.  I would again suggest we survey what other programs do to get a feel for what options have been tried before and if there are methods we do/don't like. We aren't the first to play this game.

And triggering on something like the 'error: unknown function...' might work, but will require learning how the error handlers are currently called.
Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

Rik-4
On 04/27/2018 11:10 AM, Nicholas Jankowski wrote:
> > GUI would probably be easy but CLI may be tricky
>
> hmm.. I was thinking the opposite actually. Also, a CLI option would work
> in either case, whereas a GUI option would require a CLI option for
> --no-gui users.  I would again suggest we survey what other programs do
> to get a feel for what options have been tried before and if there are
> methods we do/don't like. We aren't the first to play this game.
>

I agree.  There is no need to reinvent the wheel if there are already some
good approaches used by others.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

Rik-4
In reply to this post by Sudeepam Pandey
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).

> > 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.

> 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.

> > 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".

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?

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

Sudeepam Pandey
In reply to this post by Rik-4


On Sat, Apr 28, 2018 at 12:03 AM, Rik <[hidden email]> wrote:
On 04/27/2018 11:10 AM, Nicholas Jankowski wrote:
> > GUI would probably be easy but CLI may be tricky
>
> hmm.. I was thinking the opposite actually. Also, a CLI option would work
> in either case, whereas a GUI option would require a CLI option for
> --no-gui users.  I would again suggest we survey what other programs do
> to get a feel for what options have been tried before and if there are
> methods we do/don't like. We aren't the first to play this game.
>

I agree.  There is no need to reinvent the wheel if there are already some
good approaches used by others.

--Rik
 
Can you two suggest some programs that I could look at? Earlier jwe had written that GCC has been using a suggestion feature so that is one program we can start with.
Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

Sudeepam Pandey
In reply to this post by Rik-4


On Sat, Apr 28, 2018 at 12:25 AM, Rik <[hidden email]> 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.

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.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

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


On Sat, Apr 28, 2018 at 12:25 AM, Rik <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: UI/UX implementation for suggestions

Sudeepam Pandey


On 28 Apr 2018 2:11 a.m., "Rik" <[hidden email]> wrote:
On 04/27/2018 12:52 PM, Sudeepam Pandey wrote:


On Sat, Apr 28, 2018 at 12:25 AM, Rik <[hidden email]> 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.