Friday after work I realised that 90% of my IDE time now is just the commit/diff view — and even good IDEs feel heavy for that.
So over the weekend I built a dedicated native tool for just that. Kyde is a macOS git commit + diff editor with one goal: be fast, do Git well.
I'm curious whether anyone else mostly opens their IDE for git operations these days.
It's open source, and there's a signed app in Releases.
Another possible useful feature would be to add "open in system" or similar in the right-click menu for a file, to open the file with whatever application the OS has bound to it.
EDIT: I see there's a plugin thing that when clicked installs the highlighting. Cool!
EDIT: Also missing is selectively staging lines of a changed file to commit. I would actually change the behaviour of the Git UI so that it matches the VSCode one, to reduce the learning curve. Most people already know how that works, no need to make them learn a new UX.
>open in system:
Isn't that reveal in finder? I did add this if so :).
> selectively staging lines
Oh I've never actually done this! But I think I understand, so just pushing a few lines in a changed file. Fun! I've always used a different IDE where I don't think that's a thing. I'll add an issue.
But the terminal already has excellent diff and commit tools.
I think I've tried the git command line "interactive" mode, and is really painful. I find myself going to an IDE, selecting the line and right-clicking + "stage selected ranges" to achieve that.
What were your biggest challenges in making this?
Opus 4.8.
> What were your biggest challenges in making this?
UI that had to react due to things such as the window size changing, specifically with horizontal and vertical scrolling and getting it to work with mouse drag + text selection via shift and arrow keys. It was a lot of back and forth. In the end after getting it working for the main editor I (Claude) turned it into a with_scrollbars decorator method.
Knowing to splitting god functions before they sprawl / emphasising regression tests, and specifically frame rate regression has helped me a lot so far I think.
There is not one singular answer for everybody.
It seems the AI coding is just the software version of Temu. Lots of cheap stuff but none of it is very good and it breaks pretty easily when you try to do anything outside of a very very small list of uses.
Also it's just quite fun.
My guess is this made it to the front page solely from the Rust boost.
> ~120fps scrolling a 37k-line package-lock.json — viewport virtualization + off-thread highlighting.
When it's a static PNG of an extremely small diff.
I'm flagging the post as spam, that's what it is.
What's the difference?
How is this different than X company saying we build Y, when they literally paid people to do it for them?
RE a month usage, that is a good idea, I will use it for a month and do a more long-form post.
I've been using it since I started building it, and have not touched my IDE, thats the goal. All commits to the repository have been made via the tool itself.
You seem to have one of those three. I’m not sure what your coding background is, but debuggers/profilers are incredibly useful and important, and it’s essentially malpractice for a developer never to use them.
> OP is smart to adjust to change
When did I tell OP not to change? My comment was about how my own workflow has changed radically in the last couple of years.
> the moment I stop using my IDE, you’d tell me don’t know what I am doing??
What? I didn't do anything of the sort.
> Dude, I probably was writing assembly code by hand when there were no IDEs and you were still trying to figure out the taste of Play-Doh
This is incredibly childish. If you really are as old as you imply, the cringe is all you, friend.
Just wait for the moment you need to write code for an embedded platform that doesn't have a debugging mechanism.
I've been programming for more than 30 years. Funnily, I used to use debuggers A LOT (in Borland Turbo C++ DOS "IDE" times, Visual Basic, Eclipse, Netbeans, Adobe Flash Builder, etc). But nowadays I seldomly use the debugger, if at all.
Very close to 0% of programmers on this site are doing this. The vast majority are writing JavaScript/TypeScript, Python, or some other high-level language and targeting web platforms.
> But nowadays I seldomly use the debugger, if at all.
That might be fine for you and your use cases, but it's not fine for CRUD app developers who are essentially passing and mutating data around databases and state machines.
I've done a mixed bag of these, but yep ultimately mainly just CRUD now days and yep that's all we're doing. It's what a lot of us are doing!
I understand there are people who haven't used debuggers before and don't know what they're missing out on, but there's no excuse for that anymore because it's become much easier to set them up and use them.
To be totally honest, having such an absolutist view makes you look inexperienced -- and accusing people who disagree of "malpractice" is absurd.
Debugging and profiling has always been outside of the IDE for me, except when I started out as a Java Developer.
I don't and have never understood why someone spins up a full-weight IDE and then not used that same GUI to manage their debugger, since you get a lot of added benefits from that (being able to copy/paste from the editor to code evaluation/REPL for example).
I wasn't trying to criticize this early work at all. It looks like a fun and promising project!
Profiling is a tool meant for processes that relate to performance, or hot spots. Debuggers when integrated well[1], are great tools but compete with print based debugging which is a much more general skill one uses and needs to learn.
Let's reserve malpraxis considerations for writing code without any true thought given for security, privacy, accessibility and human rights affected.
[1] and I don't like the interface of any of the debuggers I used. Except maybe in ghci, if I had the patience to script a Tcl/Tk frontend one day.
You should absolutely be adding logging, including optional verbose logs, to code. It’s a form of self-documentation and a major convenience during maintenance.
But it doesn’t compete with or replace using a real debugger, which allows you to step through your stack at any point and see potentially many megabytes of state that you literally can’t consume from a text console.
I’m referring to server-side work when I say to use a debugger in the IDE, not something targeting the browser.
Is this something you expect other people to use?
Are you planning to maintain this?
Are you making a point about ai capabilities?
Is this just a joke?
I guess I don't really understand the point of posts like this.
No. They had nothing to do with the code. The project is not only the code.
> and anyone else could pay an ai to make the same thing easily?
This assumes that the difficult part is typing code, but in reality the most difficult part is to know what to build, specify it, evaluate and iterate on it.
If it were truly as easy as asking an AI once, then everyone would already be shipping successful products daily.
AI just lowers the bar to entry.
I could not agree more! I think there's a finite group of people who have a strong software engineering background who really know the rewarding pain and are able to embrace AI in an optimistic way.