I'm leaving the Zed extension pointing to the older commit of the
Tree-sitter grammar, I'll update that after this version bump. It's
a bit awkward to do it this way around, but there are circular
dependencies that can't be avoided. Maybe with an attack on SHA1 it
can be done in theory, but let's not go there.
I am tired of bumping the version number in 5 crates every time I need
to make a new release. RCL is built exactly to deduplicate that kind of
thing. So let's see how far I can get with generating all of this!
This fixes a longstanding issue where reporting errors that we have to
blame on just the document's result in general got blamed on its full
span, which is often a comment and not the offending value. Now we blame
it on the inner body expression, which is more natural.
I am adding an example on the website for the json querying, and the
json value I want to only evaluate once and then keep it around. It
would be wasteful to re-evaluate it on every keystroke. So expose a
function to return an opaque value that we can later pass back in.
It renders ugly no matter what I try. The best thing would be to not
treat it as opaque monospace, and render html divs for those errors.
Then I can style the border using css. But then I need to edit the error
printing quite a lot, I don't want to do that right now. For now this is
good enough. One thing at a time.
For the wasm module, I want to generate html spans. So I need a way to
have the strings where the whitespace and newlines and such are already
handled, but the markup has not yet been applied. So split the
pretty-printer output into two stages, one where we build these spans,
and then one to write it to a string.
I fear this does make the output less efficient. Also all those &str
pieces that are two pointers wide for mostly tiny string fragments, that
hurts. But I must resist the urge to optimize prematurely.
I measure no significant difference:
Benchmark 1: /tmp/before eval --color=ansi big.json
Time (mean ± σ): 11.162 s ± 0.384 s [User: 10.080 s, System: 1.063 s]
Range (min … max): 10.496 s … 11.922 s 10 runs
Benchmark 2: /tmp/after eval --color=ansi big.json
Time (mean ± σ): 11.176 s ± 0.293 s [User: 9.831 s, System: 1.326 s]
Range (min … max): 10.823 s … 11.632 s 10 runs
Summary
/tmp/before eval --color=ansi big.json ran
1.00 ± 0.04 times faster than /tmp/after eval --color=ansi big.json
Now the webpage doesn't throw any errors, and if it does report -1 for
an input that has a syntax error, and 0 for an input without syntax
errors, so this far it seems to work!
