jrop

An Introduction to General Systems Thinking by Gerald Weinberg. I've found his writing style to really land with my brain.

Yeah I though llama.cpp had this during the very early days, if my memory serves me correctly.

Ha, mine's weirder, I think? I wrote a React-like renderer in Lua that renders into Neovim buffers[1], then built a pile of apps on top, including an (unfinished/experimental) HN reader[2].

[1] https://github.com/jrop/morph.nvim

[2] https://github.com/jrop/tuis.nvim

I forget the story, but isn't this the origin story of one of solutions to one of the hard problems in mathematics? The story goes that the student shows up late, and misinterprets the final slide to be homework, and it turns out that the professor was showcasing a hard problem. Thinking that the slide was homework, the student takes it home and solves it.

EDIT: In 1939, George Dantzig was a graduate student at UC Berkeley studying under the statistician Jerzy Neyman. He arrived late to class one day, saw two problems written on the blackboard, assumed they were homework assignments, copied them down, and turned in solutions a few days later. He apologized for being late -- the problems had seemed "a little harder than usual."

Ha! Well done, sir.

The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim.

Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet.

Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.

On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight.

For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs).

[0] https://neovim.io

[1] https://github.com/jrop/morph.nvim

[2] https://github.com/jrop/tuis.nvim

Glad I'm not the only one who does this.

An old favorite. "How stupid can you get, animal?"

I really prefer to lock the version numbers instead:

    mise use -g somepackage --pin

I can commit/rollback to known good versions. To upgrade:

    mise up -il

Not so long ago, I was outspoken against mise. I've since come around. It truly is a fantastic tool.

That is a valid point of view. For me, however, I have found a huge productivity boost being able to stay in Neovim for extended periods of time. That's not to say that my way is the only right way, but the more I'm able to accomplish in Neovim, the less friction I personally experience.

On k8s/devops tooling: I'm building tuis.nvim [1] — Docker and Kubernetes management as Neovim buffer TUIs, built on morph.nvim [2], a react-like UI framework for Neovim. Stay in the editor (if you already use Neovim, of course) instead of switching to k9s, works over SSH, same Vim keybindings you already use. Also has plugins for Bitwarden, process management, and file exploration.

[1] https://github.com/jrop/tuis.nvim [2] https://github.com/jrop/morph.nvim

I've been working on exactly this with morph.nvim [1] — a React-like component model (h(), component lifecycle, reconciliation, extmark-based styling) for building declarative TUIs. It uses Neovim as a base, which might seem like an odd choice, but Neovim gives a lot out of the box that most TUI frameworks don't: syntax highlighting, extmark tracking (i.e., editable regions that feed back into the component state — type in a filter and the UI re-renders around it), and navigation that Vim users already know without learning yet another keybinding layer. Built on top, tuis.nvim [2] ships real plugins — Docker, K8s, Bitwarden, process manager — all as native Neovim buffer TUIs. No Electron, no separate app window, runs over SSH.

[1] https://github.com/jrop/morph.nvim [2] https://github.com/jrop/tuis.nvim

So far, it's just a flash-banner on their `/code` page. I don't see any announcement other than folks mentioning that they are getting email announcements about its release.

Tommy Emmanuel apparently learned by transrcibing, famously thinking that both the bass line and guitar lines he was hearing were a singular "guitar part". Just by having his expectations (incorrectly) raised, he rose to the occasion and played both parts.

I forget where I heard this story -- it's probably either rather famous, or buried in an interview somewhere.

As others have said, the fact that they're letting the ecosystem settle before including something out-of-the box is beneficial in some sense. It's allowed time for experiments (including my own "how would I do UI in Neovim: morph.nvim [1]").

For some, this stage of a project attracts tinkerers and builders, and lets the community shape how things are done in the future. It's not always practical, but it does have a certain appeal.

[1] https://github.com/jrop/morph.nvim

I assume that you've tried Termux and somehow that doesn't meet your needs? (Also, you didn't specify whether you are on Android/iOS)

Right? That's the only reason that "coding with LLMs" works at all (believe me, all at the same time, I am wowed by LLMs, and carry a healthy level of skepticism with respect to their ability as well). You can prompt all you want, let an Agent spin in a Ralph loop, or whatever, but at the end of the day, what you're checking into Git is not the prompts, but the formalized, codified artifact that is the bi-product of all of that process.

We have been rewatching Clone Wars as a family, and I, for one, find this terminology hilarious given the use of it in the series towards the separatist droids.

This sounds like a really cool project. What challenges have you encountered so far?

I don't buy this. I've long wondered if the larger models, while exhibiting more useful knowledge, are not more wasteful as we greedily explore the frontier of "bigger is getting us better results, make it bigger". Qwen3-Coder-Next seems to be a point for that thought: we need to spend some time exploring what smaller models are capable of.

Perhaps I'm grossly wrong -- I guess time will tell.

Between GLM-4.7-Flash and this announcement, THIS is what I'm excited to see in this space: pushing the capabilities of _small_ models further and further. It really feels like we're breaking into a space where models that can run on hardware that I actually own is getting better and better, and that has me excited.

Wow, I really want a slide rule watch now.

Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.

To be clear, I don't try to Nix-everything. I just use it to 1) install a bunch of CLI tools to my nix-env, and 2) dev-shells. That's pretty much it, though. Even that is a huge boon. Even so, I'm keeping an eye on mise, for sure.

That's what I meant and didn't communicate well. I'm wishing for short-form syntax of lambdas, to be clear.

Yep, though I'm still trying to hit my stride recording videos. I don't release regularly because of lots of amazing $life things.

https://www.youtube.com/@nocturing

If you want a sneak peak of what I want to walk through, check this repo (see the examples/ folder): https://github.com/jrop/u.nvim

I'm actually trying to work on a video-series to do just this. I've made my own rudimentary plugins reproducing several popular ones, and would like to walk through how I made: a) file-tree b) picker/fzf replacment c) hop/leap replacement d) surround plugin e) code-formatter f) hydra (sub-modes) g) many "UI" (interactive) buffers, etc.

None of these are published because the popular ones are better and provide more functionality, but I want to share what I believe is more valuable: what I learned while writing them.

I always wrote Lua off, scoffing at the 1-based indexing, until I was "forced" to learn it thanks to Neovim. What a delightful little language it is. I do wish I could do certain things less verbosely (lambdas would be nice) -- but then again, I defeat myself by suggesting it, because not having all the features makes Lua so approachable.

Mise is a hard sell for me when I can have pure Nix-shells. However, I can see this gaining wider adoption since it's learning curve is so much lower than Nix.

Neovim + Git + Aider seems to get close to perfection.