On 14/01/21 17:36, John Snow wrote:
The sane way to evade the language design problem is to use the existing
QMP language.
I wouldn't mind implementing this for version 0.1 -- just allow
copy-pasting JSON into the input bar -- it's a feature I wanted anyway.
I think the only way out of language design is to instead design a TUI
for inputting JSON. For example:
> * after typing the ' for a key you can autocomplete the next field,
using the TAB key similar to vi
* after typing the : the TUI tells you the field type
* after typing the ' for an enum, the TAB brings up a menu to pick an enum
* after typing the last character in a key or value you automatically
get a suggestion for what to type next (comma and next apostrophe after
a value, colon and possible apostrophe/bracket/brace for a key)
One idea that has worked for me in the past was to write a mockup that
shows what things are going to look like, with fake user interaction.
You would have something like
// {
keypress("{")
show_suggestion("'")
// '
keypress("'")
start_autocomplete_choices(["execute", "arguments"])
// TAB
await asyncio.sleep(1)
do_autocomplete()
// '
await asyncio.sleep(1)
keypress("'")
// string argument, propose ' for the value automatically
show_suggestion(": '")
// TAB
await asyncio.sleep(1)
do_autocomplete()
start_autocomplete_choices("query-status", "query-kvm") # many more
etc.
Then you plug in an incremental lexer, so that you can e.g. replace
show_autocomplete(": '")
with
lex_state(Lexer.AFTER_KEY); // this would come from the lexer
show_autocomplete("'") // this would come from the schema
And then again plug the incremental visitor to autocomplete on the
schema types.
Another advantage of this approach is that you also have a natural API
for the mocks, and thus it becomes easier to write testcases.
Paolo