Re: cleanups with long-term benefits (was Re: [PATCH] schemas: Add vim modeline)

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 31/07/20 17:07, Daniel P. Berrangé wrote:
>> The QAPI JSON-but-not file format is a case where I think we should just
>> adopt a standard file format no matter what. A conversion will have some
>> short term work, but this is really simple data to deal with and the code
>> involved is nicely self contained. Again I'm not saying QAPI maintainers
>> must do it, just put the idea out there as a piece of work that would
>> be welcomed if someone is interested in working ont.
>
> The main issues with JSON-but-not in QEMU are:
>
> - the 64-bit integers, which does not apply to the QAPI schema though

QMP only.  The QAPI schema does not use JSON numbers at all so far.

> - the comments, which are a common extension to JSON (see JSON5, NodeJS
> config files, json_verify's -c option, etc.) so I find it quite surprising
> that no off-the-shelf Python component can parse JSON + comments

QAPI schema only.  QMP does not support comments.

> - the single-quote strings, which are not particularly useful in QAPI schema

Every single string in the QAPI schema uses them, though.

I have no idea why Anthony put them in the QAPI schema language.

We could remove them from the QAPI schema language.  Flag day, and
git-blame becomes pretty much useless for a couple of years.

Removing them from QMP would be painless for QEMU itself, but could
upset QMP clients that (unwisely) use them.

> If we changed the single-quote strings to double-quote, jsonc.vim
> (https://github.com/neoclide/jsonc.vim) seems to support JSON + comments.
> In Emacs you'd probably add an epilogue like
>
> (defconst json-mode-comments-re (rx (group "#" (zero-or-more nonl) line-end)))
> (push (list json-mode-comments-re 1 font-lock-comment-face) json-font-lock-keywords-1)
>
> Did I miss anything?

Let me reiterate that parsing the lower layer of the QAPI schema
language is the trivial part (because we made it trivial, accepting a
considerable hit to ergonomics).  For basic editor support, parsing the
lower layer is all you need.  But to truly work with the schema, you
need to grok the (less than trivial!) upper layer.  Making the lower
layer slightly more trivial is not going to help with that.

We can of course indulge in buyer's remorse on our choice to develop our
own schema language for QAPI.  But that's separate discussion.

As long as we have our own QAPI schema language, we should use a single
frontend for working with it.

> Besides that, why are we using Python and not JavaScript in the mode line?

Falls apart for # comments.  JavaScript uses // and /* */.

[...]