But by using the same variable-width font that the rendered comment uses, GitHub's default gives you more of a wysiwyg experience than a monospace font does. With syntax-highlighting it's an even more wysiwyg feel, but with absolutely none of the content ambiguity that richtext normally brings with it.
I came away really impressed with GitHub. For any given decision, it's hard to tell if the market victor won because of their good taste or if they won in spite of that particular decision and there was somewhere else where the good decisions were decisive. But as the GitHub issue/PR commenting system stands today, I have a hard time finding much to gripe with (except the missing syntax highlighting, of course).
But I find the other two features to be less useful, personally. I tend to do all writing in my favorite text editor (where I'm writing this now), which is already configured with syntax highlighting, and all my editing preferences. I can save my work at any time, and always have a local copy of it. In contrast, typing in textareas is a cumbersome and risky experience no matter how friendly the UI is. One wrong click or keypress could waste minutes or hours of your time. We all have our workflow preferences, of course, but I would encourage any technical person to use their editor instead. If you don't like manually copy/pasting text back and forth, there are browser extensions that automate opening up an editor, and syncing the contents with a specific textearea.
I watched your video walkthrough, and as someone who still uses LLMs exclusively via a conversational UI, it's shocking to me that it took you 7 minutes to update the "corpus" for the LLM, and run several commands, only for the actual fix to be a single-character change in a CSS selector. Sure, the difficult thing is knowing which file and character to change, but given the issue, any developer familiar with the codebase would instinctively know where to look first, and fix the issue in a fraction of that time. Maybe even add a test case for it.
This is far from the efficiency and speed these tools were promised to deliver. Aside from the fact that you admit not having an understanding of the testing framework you vibe coded, when your entire development workflow depends on it. If this is the future of software development, as you claim, what a bleak future it is.
BTW, you have a very nice shed, Ned. :)
Have you tried https://ghosttext.fregante.com/
> typing in textareas is a cumbersome and risky experience
Exactly! Forget syntax highlighting, that's the real problem to be solved! (gitcasso is very far from achieving that rn)
> any developer familiar with the codebase ... fix the issue in a fraction of that time
Fair point. I published an example which was easy to follow rather than an example which showed off the tooling at its "max strength". I recorded a different take where I added support for issues being opened within a GitHub Project. The scraping there is a lot more complex, fixing one case tends to break another, and the AI can solve it in pretty much the same time, but the video felt too confusing to bundle with the launch.
> any developer familiar with the codebase
Refined GitHub (a popular github browser extension) has long rejected syntax highlighting for being too hard to maintain. So part of the goal here is to automate that maintenance - hopefully there won't even be a developer who is currently familiar with the codebase pretty soon. The slowest part by far is capturing the snapshots in the first place, which could/ought be automated.
> you have a very nice shed
Thanks imiric! And thanks for sharing your thoughts :)
1. It'd save a lot of time if one could just click a Markdown PR description and start editing it, without entering edit mode first.
2. Thanks to the following prompt, I barely write PR descriptions these days.
> Run `gh pr view` then `gh pr edit` to fill out the PR description. Use my words verbatim as much as possible. Be brief. Use tasteful markdown formatting.
As someone who has to read a coworker's AI-generated slop PR descriptions every day, what a bummer
But when I tried your Chrome extension, I found a problem - the comment box became light mode, when GitHub is in dark mode...
I have opened a GitHub issue about this problem.
> We are not going to mess around with the comment box with syntax highlighting, which numerous people tried and failed due to GitHub updates or edge cases that are not so edgy.