ubolonton_

I introduced ClickHouse at my company 2 years ago, and came to the same conclusion.

For observability, it seems to have become the dominant storage choice for new observability startups.

And the newly introduced JSON type would help it winning even harder.

Ok, understood. I was confused by the phrase "parse of that tree".

Tree-sitter's output is closer to being "dynamic" than "untyped", though.

It's not too hard to build a layer on top of tree-sitter (out of the core lib) to generate statically typed APIs. I haven't felt the need for that yet, but it may be worth exploring.

> actually process/compile it

At work, I built a custom embedded DSL, using tree-sitter for parsing. It has worked well enough so far. The dynamically-typed nature of tree-sitter actually made it easier to port the DSL to multiple runtimes.

> provide 100% accurate code intelligence

Totally agree that tree-sitter cannot be used for this, if we are aiming for 100%.

What do you mean by “parse of that tree to get useful structures out”? Can you provide some concrete examples?

In Emacs, local-function-key-map has this entry:

    C-x @ s                   event-apply-super-modifier

So to get s-g to work, you'd configure the terminal emulator to convert the Command+G key press to the C-x @ s g sequence.

    # Hex code (iTerm)
    0x18 0x40 0x73 0x67

    # kitty (without Emacs doing the integration)
    map cmd+g send_text all \x18@sg

Konsole somehow seems to have this done for the whole English alphabet, so it just works out of the box there.

For 2-modifier bindings, I guess you can add a creative entry to local-function-key-map. (If the other modifier is Shift, you can just use uppercase letters.)