Re: Call for Google Summer of Code 2021 project ideas

[Paolo Bonzini]

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