The Gram Code Editor - 2026-09-30

Great, I saw your PR. We require signed commits so didn’t check but if you can please sign your commit, but yeah it looks good to me

i converted someone to gram >:3

> Great, I saw your PR. We require signed commits so didn’t check but if you can please sign your commit, but yeah it looks good to me I think I've done it. I just --amend --signoff. is this Ok? ↺

@frafav ah no signoff is something different. There is a guide here: https://docs.gitlab.com/user/project/repository/signed_commits/ssh/

oh, I didn't know signed commits were mandatory

I never set that up, it's the opportunity I guess

yeah it’s gotten easier now that signing with SSH keys is possible, someone asked for it and I hadn’t set it up myself either so I decided that it was worth giving it a go

When I build from source, the python debugger does not work: > ERROR [debugger_ui::debugger_panel] No debugpy adapter found and allow_binary_download not set When I use the prebuilt binaries it works. Has something changed? Or should I build differently than just `cargo build`?

> yeah it’s gotten easier now that signing with SSH keys is possible, someone asked for it and I hadn’t set it up myself either so I decided that it was worth giving it a go hmm I will set up opengpg I think, since I plan to dive into this a little bit for an XMPP/Deltachat gateway :) ↺

Yes, something HAS changed! I have found more ways that the editor sneakily downloads and installs stuff behind our backs, and have been plugging those holes.

> Yes, something HAS changed! I have found more ways that the editor sneakily downloads and installs stuff behind our backs, and have been plugging those holes. oh ok. but it should be available without download, since with latest prebuilt gram binaries the debugger just works? ↺

It has also unfortunately made the editor a lot more painful to use. This is really the main thing holding back the next release. I want to figure out a better user experience around permissions, and there are still holes in the security model

no in 3.3.0, the editor will just silently download stuff to get the debugger working

but on main, you need to allow it. The debugger adapters are listed in the language server configuration view as well right now, as a temporary fix

> no in 3.3.0, the editor will just silently download stuff to get the debugger working yeah but what I mean is that on this machine, the stuff has already been downloaded so shouldn't it be used? or does it download it every time I launch the debugger!? ↺

because of how the APIs work, the check happens before it even looks to see if anything is already downloaded

oh I see, thanks for the explanation

2026-09-30T09:34:50+02:00 INFO [dap::transport] Debug adapter has connected to TCP server 127.0.0.1:40005 2026-09-30T09:34:50+02:00 ERROR [debugger_ui::debugger_panel] error: process exited before debugger attached. I allowed the download but it crashes without a useful message, I'll investigate a little bit…

hmm that seems unrelated.. but try restarting after giving permission if you haven’t

a restart did not change anything. guess it's time for me to dig into how DAP/debugpy works :)

hm. I have only tried the codelldb/rust debugger after making the changes, maybe I have broken something.. not at all impossible

do you have an idea which commit might have broken it? I'm struggling to even understand which `debugpy` "binary" is even used by gram -_-

I bet there is an npm package involved somehow…. will take a look

ah no it’s a python wheel it’s downloading

slightly more sane than going through npm :)

I found something interesting with a debug build: 2026-09-30T10:42:22+02:00 INFO [dap::transport] Debug adapter has connected to TCP server 127.0.0.1:46653 2026-09-30T10:42:22+02:00 DEBUG [dap::transport] stderr: Content-Length: 138 2026-09-30T10:42:22+02:00 DEBUG [dap::transport] stderr: 2026-09-30T10:42:22+02:00 DEBUG [dap::transport] stderr: {"seq": 1, "type": "event", "event": "output", "body": {"category": "telemetry", "output": "ptvsd", "data": {"packageVersion": "1.8.22"}}}

Isn't it weird that this json payload is in stderr? intuitively, I believe this should go through the tcp socket instead

yeah seems odd

but not clearly an error? hm

maybe debugpy has a stdin/stdout mode and a tcp mode, and somehow gram launches it in stdin/stdout mode instead of TCP?

but then "Debug adapter has connected to TCP server 127.0.0.1:46653" is surprising…

yeah sounds like maybe something has changed that makes it disconnect on the first message or something

So many issues with the code around the debug adapter to work out.. first off it’s just throwing away the relevant error when the connection fails, second it’s just downloading the latest release so totally could be something that has changed in debugpy itself

alright I have a fix

ah nice

with the new dap settings in the config file

when user_args is unset, debugpy is called without the proper CLI args

aah

I don't know if my fix is good, but it's ```diff - pub args: Vec<String>, + pub args: Option<Vec<String>>, - args: content.args.unwrap_or_default(), + args: content.args, ``` for dap/src/settings.rs

and ```diff - let user_args = dap_settings.map(|s| s.args.clone()); + let user_args = dap_settings.and_then(|s| s.args.clone()); ``` in crates/project/src/debugger/dap_store.rs

btw something's off with the formatter settings, I don't do rust at all so I have not tweaked any config, and yet when I edit gram code with gram, it reformats parts I don't touch, eg: ```diff - binary: content - .binary - .map_or_else(|| DapBinary::Default, DapBinary::Custom), + binary: content.binary.map_or_else(|| DapBinary::Default, DapBinary::Custom), ```

I don't know if the checked in gram/rust-format settings are wrong, or if it's you committing files that aren't formatted according to the defined rules

that's where pre-commit hooks are nice :)

hmm yeah… let me see what happens if I run cargo fmt —all

hah yeah.. not sure when that changed

shall I open a PR with the 2 diffs above? I _think_ it makes sense but man is the codebase complex. What I don't like is that it touches `crates/project/src/debugger/dap_store.rs` which was not touched by recent commits, so maybe the fix should be elsewhere.

let me see, I think the fix should be to change DapSettings to make the individual fields Option<>.. right now it assumes that if the dap settings object exists, all the fields are valid

so adding the permission fields is what broke it

yes, that is my conclusion too

I guess if I had debugpy installed in the project's venv, I would not have needed to add the dap entry in config.jsonc and it would have worked (provided gram actually picks up debugpy without downloading it when available, which I think happens from my skimming through the code) ✏

alright I'll use my dirty fix for now, and let you fix this however you want then :) I don't care about taking credit for the investigation, you commit and it's fine!

I’ll set you as Co-Authored-by: if that’s OK, will go through the other debug adapters and make sure they don’t do anything weird.. and also make the same change for user_env

I'm fine with that but I hope I'll be able to handle the fame & money that'll come with that. ✏

I'm fine with that but I hope I'll be able to handle the fame & money that'll come with it. ✏

I managed to sign my commits in my "commit hook" PR, yoohoo! now there will be a green 🔒 next to stuff I push to codeberg, that'll look more professional! ^^

lol

where is Gram hosted?

> I managed to sign my commits in my "commit hook" PR, yoohoo! now there will be a green 🔒 next to stuff I push to codeberg, that'll look more professional! ^^ nvm 😭

i love codeberg!

yes, codeberg 👏

DF

> @frafav ah no signoff is something different. There is a guide here: https://docs.gitlab.com/user/project/repository/signed_commits/ssh/ ohh, I didn't know, I've set the option as default ↺

I also had to verify the key :P. it's 15 years that I'm using git and I knoe basically 1% of these security quirks

hehe yeah I had never used it before either..