The Gram Code Editor - 2026-10-01

Hm I see that LSP binary paths and SSH connections are stored in the settings.jsonc file. I sync my settings.jsonc between computers using git because I want all my computers to share keycap, theme, font sizes, etc, but SSH connections and their project paths aren't something I would want public and LSP binary paths have to be configured per computer

Is there some mechanism to have some of settings.jsonc in git and some of it not? Something like an include directive which would let me have per-machine config in the main settings.jsonc but have that include a synced shared-settings.jsonc?

You can have per-project settings.jsonc by checking it into your project under .gram there. But no per-machine include yet no

But this is something that annoys me too and I want to fix. Just haven’t settled on what the fix would be yet

The easiest solution would be: gram reads settings.jsonc and shared-settings.jsonc and merges the two objects, with settings.jsonc taking precedence (so local settings can override shared settings). Gram would not modify shared-settings.jsonc and would not treat it as an error if it's missing.

A cleaner solution maybe would be to split settings.jsonc into one settings.jsonc and one local-settings.jsonc, where all settings which it doesn't make sense to share are in local-settings.jsonc

There is already support for merging settings used to merge the defaults and the user settings, but the code is such a mess that I end up wanting to rip it all out every time I look at it 😅

Is the problem that it uses serve to read the jsonc files into structs and therefore needs bespoke code to merge Rust structs? Because a generic function to merge two JSON-style object graphs shouldn't be that ugly

Not kidding, I reduced the binary size of the editor by 10-20MB just by refactoring the settings code

That's wild

it’s all generic code over every setting , and every setting for some reason is parsed into two separate types.. which ended up generating thousands of lines of code for every setting. It’s still huge, but less than before

Sometimes, dynamic data structures based on `enum Value { Null, Number(float64), String(String), Object(HashMap<String, Box<Value>>), Array(Vec<Box<Value>>) }` are perfectly fine 😅

absolutely! Just a global function that looks up a setting by path and returns a serde_json::Value would be completely fine…

And global constants for paths so that you avoid the risk of typos, maybe even schema validation on parse time

so what I want to do (one reason I haven’t made progress yet) is to rewrite the default.jsonc into a schema which provides description, possible values, defaults etc for every setting. Then that can be used at compile time to make everything typesafe, make sure setting names are correct etc

Oh you could generate accessors based on the schema too probably

another annoyance at the moment is that every setting has to be defined and documented in at least three places.. instead of generating the UI and docs from a single source of truth

yeah

but yeah this is just one of many such things to get to.. hehe. Also need to rework extensions…

at the same time I don’t like breaking anything so making big changes takes a lot of care

To avoid that issue where they can download stuff? What's the idea there?

I've been thinking that Zed extension compatibility is a great benefit for Gram, but as it's a hard fork, Gram and Zed will probably drift away from each other to such a degree that eventually, Zed extensions won't work with gram anymore

Well, I want to get rid of the need to compile rust to wasm and have a whole toolchain for that. The current extension API is also very limited, it’s basically “give me a language server” and the the extension goes off and downloads stuff however it wants

so I want to make the permission system work and more ergonomic, better UI around that.. but also make extension search, updating, pinning to a version etc work

A Lua runtime is probably gonna be tiny compared to a WASM runtime + compiler toolchain heh

I will keep compatibility with themes and such as long as I can, but for language support I will just try to rewrite every popular extension for gram in the new format. And until it’s usable I can just keep the old extension support too

I have a game I'm working on which I want to be extensible in a similar way where it compiles source code, but it turns out that distributing LLVM + Clang on different platforms is damn difficult

yeah it sucks! I thought Wasm extensions was a good idea until I saw the toolchain it drags with it

now I think I will go for lua or something like the helix plugin system

we’ll see

So many things would be nicer if LLVM wasn't this gigantic unmanageable beast

yeah..

Do you know of a nicer schema language than json-schema? It's serviceable but pretty unergonomic as far as IDLs go, protobuf and cap'n proto are so much nicer to work with but don't quite fit the same niche

hmm not really, I have been looking at kdl but it’s more like a schema construction kit

the kdl files look great though, can make them very readable

was looking at replacing protobuf with https://crates.io/crates/rkyv just because protobuf makes the compilation much slower

but capnproto should also be good

but yeah actually.. why not use that for the settings too.. hmm 🧐

For something like an RPC mechanism where you can verify that both sides are speaking the same version of the protocol at handshake time, something like Postcard might be interesting too: https://docs.rs/postcard-rpc/latest/postcard_rpc/

yeah that’s another one I am looking at

I don't have much experience with it but my sister has used it for microcontroller <-> host computer communication and is happy with it

(She's the one who submitted that MR recently about scaling images on first paint hehe)

nice! good, that’s all the endorsement I need really 😄

I've also read its docs about the wire format, it's all very much "yeah that's how I'd have done it too" hehe. Pretty much just simple sensible rules for how to serialise the primitives, struct fields get serialised just one after another in order

I'm not sure I understand how rkyv could solve settings though, it's another serde-based binary serialisation format/library right?

suddenly I was just wondering why the defaults are in json at all

could just put them in the code

That's true

are extensions written in rust and then compiled to wasm? in theory you don't need to compile rust, the editor could integrate a crate with a compiler targeting wasm (could be a scheme compiler like helix or lua or whatever)

does wasmtime itself depend on llvm?

I’ve looked at other options targetting wasm but nothing feels right tbh

the extensions need WASI too. And if I am changing things I feel like I might just go for something that doesn’t need compilation ahead of time. There is roto which is jitted using cranelift, but it’s pretty immature..