VSCode extension strategy

[adam-coster]

I'm not yet sure if we'll be able to adopt Gobo in our work, but if we can do it we'll want it as a VSCode extension. In that case I'd love to help out.

There are a few ways we could approach that, so this Issue is for discussion on the topic.

At a high level I see three options, in best-guess preference order:

1. A VSCode extension is added in a subfolder of this very repo, so that everything is in the same place and you maintain full ownership. I would contribute through PRs.
2. A new Pizzandy repo just for the extension is created. I personally prefer monorepos, but I can definitely see wanting to separate concerns (especially since the tech stacks for Gobo and a VSCode extension are basically non-overlapping). I would contribute through PRs or directly on main.
3. I add Gobo into Stitch for VSCode. On the one hand I wouldn't use Gobo without Stitch, so this would be convenient. But I think it's better to keep them decoupled so that you have full project ownership, and so that people could use it with other VSCode GML extensions, and since it's very unlikely we'd be editing Gobo on our side (the tech stack is very much outside my wheelhouse!).

What do you think? I've put a few VSCode extensions together at this point so I can help get the initial setup and publishing stuff figured out in any case.

[Pizzaandy]

I agree with the ranking of these options. Putting the VSCode extension in a top-level Gobo.VSCode folder should work.

[adam-coster]

Rad. If I get the chance to do so I'll open a PR

[movy]

Folks, thanks for great work on this and on Stitch as well (@adam-coster 👏).

I'm setting up VSCode for my son to use with GameMaker (as its own 'ide' is just atrocious slapdash mess, how did Opera come up with this??). Stitch does a great job so far, but distinct lack of auto-indent and formatting... it triggers me personally (as the kid does not care so much yet :), so I was wondering, whether this idea of integrating Gobo into Stitch or a separate extension went anywhere yet?
Or maybe there's a command line gobo that I can attach to run-on-save trigger?

Cheers!

[adam-coster]

I never got the chance to try to make this as a standalone extension. I'm not allowed to used an autoformatter on the rare occasion I touch our game projects since our lead programmer isn't into the idea (if I did more than the rare assist it'd definitely be a fight!).

I'm pretty sure the "releases" on here include compiled CLI executables, though it's been a while since I played with it. You could use a watcher utility to run it when gml files change. I'm in the Node ecosystem so I'd use something like nodemon, but if you aren't used to that ecosystem you'd have to do a lot of setup. There's gotta be some kind of utility out there that can just watch for files and re-run something though. The tricky bit will be having a watcher utility that only runs the CLI tool on the changed file (if Gobo can run on one file at a time; I can't remember that either!).

[movy]

Thanks for responding. I figured we could use something like https://marketplace.visualstudio.com/items?itemName=SteefH.external-formatters to trigger gobo on save. But it turns out, my kid really likes vibe coding in GML using VSCode Copilot (thanks to your extension Stitch), so Copilot does all formatting for him now... if he ever decides to touch AI generated code, I'll defo hook up gobo for him.

p.s. your lead, and many other gamedevs (as I saw online trying to find a decent IDE for GML), seem to be perfectly fine wasting their time on formatting the code manually, what gives?

[adam-coster]

p.s. your lead, and many other gamedevs (as I saw online trying to find a decent IDE for GML), seem to be perfectly fine wasting their time on formatting the code manually, what gives?

Every programmer goes on the same journey based on their tools. Those who started without access to autoformatters (either because they didn't exist, or because the programmer wasn't aware of them) develop very strong opinions and patterns for how they format their code so that they best understand it. Years later someone tells them, "Hey, you could do a lot less work if you RELENQUISH CONTROL of your formatting over to this robot!" But of course the robot doesn't do it the same way. And so they try it out, but find the code now frustratingly hard to read and navigate. If they didn't want to try it out in the first place, then they stop at frustration and go back to doing it manually.

It took me a few weeks to not suffer from readability problems back when I switched over to using an autoformatter. But I was VERY dedicated to the idea of not having to do that work, so I was committed to getting used to it so that a robot could do it. Now the idea of not having an autoformatter is a nightmare!

[TT-BrianFleming]

Hi @adam-coster , I know this is an old post, but can you explain how you use the autoformatter that you are using? I assume you are also using stitch? Or are you using something else? I would love for some sort of auto formatter to work with stitch / vs code!

[adam-coster]

@TT-BrianFleming we currently aren't doing any autoformatting. We're still in that scenario where if I was doing game programming I'd definitely be figuring out an autoformatter mechanism, but since our game programmer isn't looking for this feature then it's hard to justify me spending the time. It's still on my backburner for fun weekend side projects, but that list is VERY LONG right now...

[xhocquet]

I think pursuing code formatting tooling for game devs more broadly will enhance game programming as a craft, so I'm very much into the idea. Here is an active forum thread in Gamemaker which references Gobo. Feel free to share your desire for code formatting tooling and how you would benefit from it - https://forum.gamemaker.io/index.php?threads/beautifying-gml-code.107346/#post-714148

I've started some like extension work for myself (starting with a stitch view of the GML files for a given object), but given some encouragement maybe a formatter could be added in - https://marketplace.visualstudio.com/items?itemName=xhocquet.gml-helpers&ssr=false#overview