Re: Call for Google Summer of Code 2021 project ideas

[Paolo Bonzini <pbonzini@redhat.com>]

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