Unpredictable keyword completion

[pett]

Currently, if a user doesn't type enough characters to uniquely identify a command keyword, the parser basically picks one of the matches out of a hat (dictionary) and uses it. This can lead to surprising results, particularly if a user was unaware of other possible matches, or a command has been recently modified to add keywords that create ambiguity where there was none before.

The proposed change is this: if the partially typed keyword matches a keyword that is a complete subset of the other possible completions (i.e. "silhouette" vs. "silhouetteWidth"), the short keyword is matched so that the user doesn't have to type it completely. In other cases, a [non-dialog] error is raised saying that what was typed is ambiguous and listing the possible completions for it.

[Greg Couch]

Is there a test case, or does one need to be written?

[pett]

hb inter true

[Greg Couch]

Done.

[Elaine Meng]

I don’t want to have to type the whole word “silhouettes” but it is not exactly a subset of the other possibilities with “set," so it is now required.  Can we somehow change the rules to avoid the following problem, or maybe change the “silhouettes” keyword to “silhouette”?

set sil t
Expected keyword "silhouettes", "silhouetteWidth", "silhouetteColor", or "silhouetteDepthJump” 

[pett]

The same issue exists for "cartoon style arrows" where just "arrow" wouldn't conflict with the longer keywords (and the only conflict is actually in upper vs. lower case!)

[pett]

Sorry to reopen this when the problem is that we didn't specify the problem correctly the first time, but Elaine and I have talked this over and the behavior we'd like is that if there is only one possible match with the lowest "word count" (i.e. camel-case changes or underscores, depending on what the code looks at) then that gets matched. Only if there are more than one possible completion at the lowest word count would the "ambiguous" error occur (probably listing all the possibilities, not just the lowest word count ones).

--Eric

[Conrad Huang]

Accidentally added comments to wrong ticket.

[Conrad Huang]

Accidentally added comments to wrong ticket. Changing owner back to Greg.

[Greg Couch]

Checked in fix that takes into account the number of words in a keyword.

[Elaine Meng]

In current daily build (2017-11-28) "col" is interpreted as "colorAtoms" instead of "color" option of "clashes". Example:

open 1zik
show
clashes #1 col hot pink

...whereas "clashes #1 color hot pink" does work...

[Greg Couch]

Fixed. Needed sort possible completions by number of words. Note that entering the clashes command without an open structure gives a traceback:

No clashes
Traceback (most recent call last):
  File "C:\cygwin64\home\gregc\src\chimerax\ChimeraX.app\bin\lib\site-packages\chimerax\cmd_line\tool.py", line 201, in execute
    cmd.run(cmd_text)
  File "C:\cygwin64\home\gregc\src\chimerax\ChimeraX.app\bin\lib\site-packages\chimerax\core\commands\cli.py", line 2551, in run
    result = ci.function(session, **kw_args)
  File "C:\cygwin64\home\gregc\src\chimerax\ChimeraX.app\bin\lib\site-packages\chimerax\clashes\cmd.py", line 21, in cmd_clashes
    return _cmd(session, test_atoms, name, hbond_allowance, overlap_cutoff, "clashes", **kw)
  File "C:\cygwin64\home\gregc\src\chimerax\ChimeraX.app\bin\lib\site-packages\chimerax\clashes\cmd.py", line 168, in _cmd
    pbg = attr_atoms[0].structure.pseudobond_group(name)
  File "C:\cygwin64\home\gregc\src\chimerax\ChimeraX.app\bin\lib\site-packages\chimerax\core\atomic\molarray.py", line 157, in __getitem__
    v = object_map(self._pointers[i], self._object_class)
IndexError: index 0 is out of bounds for axis 0 with size 0

[pett]

Milestone renamed