The Gram Code Editor - 2026-05-16

My 2c, I love the idea of "done" software. It's not always possible, but I think we should try to rid ourselves of this expectation that software needs to be constantly updated. Gram is working quite well for me today and I thank you for your work on it.

Two ideas to help with burnout: 1) trusted volunteers to handle triage, 2) patron model where only people who financially support the project can submit issues

gryphonmyers: Oh brilliant! Nothing says 'open source' like a paywall. While you're at it, why not add a subscription tier for reading the README? Microslop already figured this out — slap 'AI' on everything, watch the investors drool, who cares if it actually works. Same energy

gryphonmyers, I like the idea of done software in theory but it seems hard to achieve for a GUI code editor IMHO.

and about idea 2, well that sounds sad to me

nicocoa: Yes, yes, it’s better to leave the issues, even if it takes more than 5 years and they still haven’t been resolved.

what?

I mean that leaving the issues open is better than closing them if the problem has not been solved.

…like in any other open-source project.

I think my main issue (heh) with how issues work on codeberg/github is the feature requests.. trying to steer those to the wiki and more of a discussion format. Also not perfect, but I want to give it a try. I wish bugs and features were separate things where features can be voted on, have side discussions etc

What's wrong with labels for issues to discriminate feature requests from bugs?

For votes, thumbs up reactions count could be used.

(I don't care much if you prefer the wiki for feature requests, I'm just curious)

I don’t like that they are treated the same in the UI, for me bugs and feature requests are fundamentally different things

bugs I just want to fix, I want that number to go down over time.. feature requests need discussion, thinking holistically about where to take the editor in the future, stuff like that

my goal is to close as many bugs as possible and add as few features as possible, if that makes sense. Bugs and features are in tension. But in the UI, they look like the same thing.

gitlab agrees with you, they recently renamed everything (issues, merge requests, ...) "work items" ✏

The counter argument is that besides the naming, for both issues and feature requests, it boils to down to an initial post + replies, ie, a discussion, just like in a mailing list, a forum or usenet; it has not changed much since. I get your point about the project's direction though.

From a practical and self-centered viewpoint, I opened a few feature requests for things that I would really love to have and that _maybe_ (obviously no promises) I'll give a try. Keeping the "issue" opened is a signal that it's worth starting the effort for me, and having it closed usually signals "this won't get merged no matter what".

I think feature requests could be handled very differently. More like a document with associated discussion threads, that goes through stages - proposal, discussion, acceptance etc

I actually already made the mistake before to start writing code for another project without opening a discussion about it first, and it was frustrating to see that the maintainer did not want this in their codebase. It's absolutely fine, and the mistake was on me: I should have started by a discussion about it :)

yeah I get that.. I tried to be clear in the message with my intent. But yeah just like the existance of an ever-growing list of ”issues” is stressful to me even though maybe it shouldn’t be, closing an issue is experienced very differently depending on which side you’re on

> goes through stages - proposal, discussion, acceptance etc This is a nice idea, but keep in mind that more process = more bureaucracy = more work (speaking from my experience as member of a spec-publishing org ^^), especially since I don't think forgejo has tooling for that.

I've seen projects use labels for that. rg "feature request:stage:discussion", "feature request:starge:accepted" ✏

that’s true, but the UI could push the person creating the feature request to take more ownership. Yeah in codeberg I guess labels is the only tool we have

But it’s tricky. There is always going to be disappointment if someone really wants a feature and the project says no

I get your point about the anxiety associated to the numbers of issues, but you should filter by label=bug or assigned=me IMHO. The naming is not great (but it's what we have). But IMHO, it's not on _you_ to fix everything, especially since IUUC you want gram to be community-thing.

> But it’s tricky. There is always going to be disappointment if someone really wants a feature and the project says no sure. some sort of governance needs to be established. the usual model is benevolent dictator and while imperfect, it sort-of works usually...? I can't share any experience here, my project has not (yet, hopefully) established a more formal (and less dictator-like) process for governance... ↺

I’m still not entirely sure what I want to do. Right now it’s just me, so I want to control it to keep my own commitment under control. I can’t force anyone to jump in, someone would have to volunteer

yeah there seems to be two models, either benevolent dictatorship or a beaurocratic nightmare, haha

xD

do-ocracy is sort of an in-between model, but it's not a silver bullet at all obviously

and it does not solve the issue of maintenance burden for new features, if doers don't stay around

it’s very easy to start just accepting any contribution because you’re just grateful to have other people contribute, but it’s hard to maintain the goal of long term stability that way. Ideally there would be a fork that tries to be more future-leaning and experimental, if someone wanted to go that way

I’m still trying to remove stuff 😄 Like there are three separate UI:s for theme selection, two separate systems for language support..

This makes sense. As I said, I can't share experience regarding any of that, XMPP in general and chat gateways in particular are way too niche for this to have been an issue for me at all xD. I do empathize with the general feeling of being close to burnout and overwhelmed with the work to accomplish.

I think I could reduce the size of the executable and the build size by a huge amount by removing the Wasm extensions and switching to a scripting language and separated tree-sitter modules like helix

so I am thinking about stuff like that more than adding UI features 😄

cool! this is what you want to work on, do that then :)

it’s a blessing and a curse for sure, I never thought anyone would care besides me

so I wasn’t really prepared for people actually to start using it

krig: I think you are doing something that exceeds your capacity. For example, even the developers of Zed did not create packages, yet you did, even though having a tarball with a curl | sh command is sufficient.

I have a suggestion that I hope will not upset anyone: it might be better to remove the packages and keep the tarball approach, because a bug in a feature like this could lead to many problems. Also, we are naturally on a platform that does not have many users (Codeberg), so the number of PRs that fix such issues is very small.

I think having .deb and .rpm via forgejo works well, and the others are mostly maintained outside the repo. But yeah there are a lot of Linux distros, haha

no way for one person to maintain for all of them

yes. try packaging rust stuff for debian official repos and have fun xD

I was using Zed flatpak previously (still installed), that's the simplest maintenance wise I thought?

The wiki idea for feature requests discussions is certainly interesting

krig: I really feel you on the stress of a high "issue" count. The fact that you can apply a filter to see just the bugs doesn't help the background anxiety of that number hanging over your head.

Plus it's helpful to clearly see how the number of real bugs changes over time, at a glance ✏

Plus it's helpful to be able to track the number of real bugs changes over time by glancing at the issue count when you visit the repo ✏

So I totally support moving the feature requests elsewhere

However, do you think we could just move/direct them to a separate feature requests repo?

The repo itself would just be a README file, but its issues board would be where all feature requests live

It seems like you came around on not closing real bugs that you have no intention of fixing, which I'm glad for. I think a "contribution needed" label could be a good solution there.

yeah that’s a good one, I will add that

a separate repo for feature requests / ideas could work, definitely

Flatpak is not that easy, at least for me so far. There’s sandboxing and permissions stuff that’s non-obvious and causes problems, it seemingly keeps saying that there’s an update available all the time…. But if we got the flatpak build in order and got the package into Flathub that would be the best yeah. Works everywhere then

Yeah, the sandboxing complicates things for sure.

An IDE really is nicer with a native package, unfortunately

https://github.com/zed-industries/zed/pull/47091 https://github.com/zed-industries/zed/pull/52012 I think this PR is good, when I accidentally delete a file or a folder where git has not been initialized i can’t restore it, it feels really bad :(

That's more likely to get fixed if you file a bug or open a PR with the cherry-picked commits

The patches look fairly reasonable apart from seemingly using a zed-specific fork of the trash crate.. I’ll need to see if their changes have been upstreamed

but yeah, a PR would be best, second best a feature request in the wiki ;)

My bad for assuming it was a bug

krig: if we're going to stick with the wiki for feature requests for now, can we label all of the closed feature request issues so it's easy to go through them and look for ones you want to migrate?

yeah I can do that when I have time

I'd be happy to help with issue triage and categorization, but converting them to a whole different format is more effort than I'd want to spend

Thanks!

@harper if you are happy to help out I could revert the wiki thing and go back to using issues, and give you permission to help with labelling? I don’t have time to sit with it right now, but I should be able to do it tonight

That sounds lovely! No rush ofc

fantastic, thank you :)

Unfortunately Forgejo still doesn't have native issue moving like GitHub does, but there's a script to do it via the API. I assume it re-creates all comments under the account you're logged in as though :/

Unfortunately, I can't test it as Codeberg is having issues preventing me from creating test repositories

If my assumption is correct though, we should make a gram bot account

hm. Maybe it’s better to just reopen the issues and keep them in the one repo. Maybe having some help maintaining them is enough to take some of the load off

@harper I have added you as a maintainer now, but I don’t have time to sort out the labels or wiki at the moment