kilo VS delta

Most of that is probably attributable to being based on Kilo: https://github.com/antirez/kilo (kinda strange they didn't link directly in their readme) - a tiny text editor written by antirez who notably also created Redis. Antirez has a bunch of really interesting side projects if you dig into their github repo.

Yeah, "micro" for an editor would be 11 kilo bytes. I bet it's possible to do a half-decent editor in C in 11KB. Antirez's "kilo" (~1000 lines of C) is 36KB when compiled with standard gcc (https://github.com/antirez/kilo).

That said, for many server-type use cases these days, 11MB isn't a huge deal. Still, I wonder if micro could be compiled on / ported to TinyGo and end up a few hundred KB? It looks like TinyGo can produce some pretty small binaries: https://tinygo.org/docs/guides/optimizing-binaries/

Anyone interested in the machinations of all of this terminal stuff should look at antirez’ kilo, a terminal text editor in under 1000 lines of code: https://github.com/antirez/kilo

There is a nice tutorial that walks through how one might write it from scratch: https://viewsourcecode.org/snaptoken/kilo/

kilo 1k of C

I always wondered how people get stuff animated on the terminal but I never had the time to look into it up until a few years ago when someone on the internet released an awesome guide on how to create a text editor in less than 1000 lines of C. What caught my attention about this was that it was based on Antirez' kilo - which is a terminal based editor.

You could start by looking at something super simple like Kilo:

https://github.com/antirez/kilo

Even I could understand this one pretty well and that's no small matter.

I just started learning Rust 2 weeks ago, and I wanted to apply my learning towards a project.Ginkgo is a small text editor built entirely in Rust. It takes inspiration from the famous tiny C-based text editor, Kilo. It also includes many Vim inspired keybindings and features such as normal/insert modes. For convenience, it also has added mouse cursor support!

Write your own editor. As an example: kilo

Thanks for the difftastic & zoxide tips.

However, I've been using this git pager/difftool: https://github.com/dandavison/delta

While it's not structural like difft, it does produce more readable output for me (at least when scrolling fast through git log -p /scanning quickly

View on GitHub

I'm currently waiting on the integration between Delta and Difftastic:

https://github.com/dandavison/delta/issues/535

Difftastic now has JSON output, whic should make it much easier to build this.

I'm surely in the minority here. I've been using Emacs for almost a decade now, but I just can't get into the Magit workflow. I've tried several times, but always end up going back to Git on the command line. I have dozens of aliases, shell integrations, a nice diff viewer[1], etc., and interacting with Git has become muscle memory. I can commit, cherry-pick, rebase, bisect, fix conflicts, etc., in a fraction of the time it would take me to navigate Magit's UI. I'm sure with enough practice, a Magit user could do this more quickly and efficiently, but honestly, with some custom-built porcelain, Git's UI is not so bad. Though this could very well be Stockholm syndrome after using it for such a long time...

For whatever reason, Magit's opinionated workflows never clicked with me. A part of it is the concern that it will do something weird to my repo that I'll then have to waste more time undoing manually. I usually don't trust sugary wrappers around tools. And another is the fact I don't use Emacs on all machines, and setting up Git on a remote system is just a matter of copying over my config and some shell integrations.

Also, on a more personal note, I find the cultish fanboyism whenever Magit is brought up slightly offputting. Does anyone have anything bad to say about it? No software can realistically be this infallible. :)

[1]: https://github.com/dandavison/delta

For looking at diffs I still prefer the command line though, and use delta to view diffs between commits or branches.