commit 4108e0d930a02ea89a0b2817e71a4bedfed70f13
author Václav Kubernát <kubervac@fit.cvut.cz> Mon Oct 29 13:32:22 2018 +0100
committer Václav Kubernát <kubervac@fit.cvut.cz> Wed Feb 06 16:39:09 2019 +0100
tree bef3307d4d28470f38f1e8e98cf327ec5cad0579
parent 39ae959892521dbc3764486f94c5cd413c27f245

Tab completion for paths

There were several problems with the implementation of the completion.
Firstly, a way to propagate completions back from the parser was needed.
That was rather easy to solve with the ParserContext class. Next problem
was prefix matching, or specifically, where will it happen. There are
three possible situations, that can happen, after the input goes through
the parser:

1) The parsing was successful and there is no more input. Then there is
no need for prefix matching and completions are returned as they are:
if there was a valid path "first/second" and the user entered "cd
first/second/". Then the whole input would be parsed and completions
would be the nodes contained within "first/second".

2) The parsing was successful and there is more unparsed input. Then the
completions need to be matched with the input and the common prefix
deleted: if there were valid paths "first/second", "first/service" and
"first/something", and the user inputs "cd first/se", then "se" would be
left unparsed and it would be used as a prefix to change the
completions: they would be "cond" and "rvice".

3) The parsing was successful, there is no more input, but the parsed
input could still be completed. This means I need to know, where exactly
(in the input string) were the completions generated. Example: if there
were valid paths "first/min" and "first/minister", and the user inputs
"cd first/min". Then the parsing is completed successfully, the user
could press enter and execute the command, or generate completions and
"minister" would pop up.

Because there is no way to see the whole input in the AST handlers, the
matching had to be done outside the grammar (that is, in the
completeCommand method). The problem is mainly with the third situation.
Fortunately, I can save the position, where the completions were
generated, and use this information in the completeCommand method. This
solution also has the advantage of less duplicate code since we do all
matching in the same place.

The last problem was when do we exactly create the suggestions. One
option was to create them right after the "node" parser succeeds (in its
AST handler). Unfortunately, that created some problems if the parsing
succeeded but no additional user input was present. To solve this, a
pseudo-parser (a nothing parser) called createSuggestions was created.
This parser generates suggestions in-between nodes, so it's not
dependent on the "node" parser.

Change-Id: I02d9b5d23d7e695bfe7a5e168d9fefe931bc04ef