Open nus-se-script opened 11 months ago
Agreed, we could instead detect if the autocomplete suggestion is already an exact match to the given command, then immediately run the command.
Although, it is non-trivial to design such a behavior. Our considerations include:
It is almost impossible to "guess" if the user is invoking autocomplete (e.g., the user wants to use list --org
later) or for run (e.g., the user wants to use list
standalone immediately). The former thus prevents users from unintentionally running commands, since autocomplete is undoable, commands are not.
Autocomplete already provides significant speed ups in this use case. For example, you may simply press l
, then TAB
, then ENTER
, to invoke list
. This is already 2 keystrokes less (67% faster) for proficient users than a hypothetical list
and ENTER
without autocomplete.
Additionally, JavaFX seems to be really weird in terms of keystroke event captures - even autocomplete itself used a bunch of hacks and inconsistent workarounds from days of trial and error to correctly interpret keyboard events.
See workaround notes at: AutocompleteTextField.java#L103, AutocompleteTextField.java#L109, CommandBox.java#L71
Thus, further polishing of how these keystroke events are distributed (e.g., to debug and correctly pass down the ENTER keystroke to the command box) was thus not really in the scope of being done by v1.4.
--
When typing commands like
list
, users have to type theEnter
twice due to the autocomplete function, slowing down the user[original: nus-cs2103-AY2324S1/pe-interim#5245] [original labels: severity.Low type.FeatureFlaw]