jrop

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

I really prefer to lock the version numbers instead:

    mise use -g somepackage --pin

    mise up -il

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.

Agree - leaps and bounds beyond anything I would have dreamed possible a few years ago...but... IDK, if I'm honest, the sound was way off too, not just the visuals. The music sounded detuned slightly, and the crowd noise was "crackly" etc. etc. It had a low-fidelity "quality" to it.

Personally, I feel mixed feelings. I'm impressed, but I'm not looking forward to the new "movies" that are going to litter YouTube et al generated from this.

I use it daily locally, and find it amusing how many only think of it as being useful on remote servers (not to invalidate your use-case -- I'm just contrasting my own use). As a precursor, I view UNIX as my IDE, of which tmux is a part: this IDE runs on Windows (WSL2), macOS, Linux, and Android (Termux). That aside, here are a few reasons I find tmux to be useful in this concoction of tools:

- Session management. I've written custom scripts for myself around this (zoxide + fzf). If you want to see how this can be used, look at ThePrimagen's workflow. I don't use his scripts but he has a good demo of how he harnesses sessions.

- Unified scrollback management - easily search the scrollback, yank it, etc. My favorite thing to do is to yank part of the scrollback, then `Prefix+B,=` to list everything I've yanked (think of this like a "clipboard manager" specific to tmux), select an entry, and press `e` to edit it in `$EDITOR`.

- This one might be a stretch, but I tend to try and use only terminal tools (without being utterly insane) because then tmux can be my "tiling window manager" no matter what OS I'm on. Oh, I have to use Windows for work? Not to worry, tmux runs in WSL2, as do most of my preferred tools, so I feel mostly at home even though I normally really dislike Windows.

- It's scriptable. Read `man tmux` and use your imagination!

Notwithstanding any of that, there are cons, the most apparent one being that I am limited to text-based tools this way. An example of this: getting images to work in tmux, though many modern terminal emulators support them, is a huge pane, so I haven't bothered.

It's on the roadmap: https://ghostty.org/docs/install/release-notes/1-2-0#roadmap

I do indeed live in the terminal (all day due to work), but tmux adds too much value for me to do all terminal management in Neovim (tmux session-management being what I use most). I've just encountered too many visual "glitches" in the Neovim terminal to rely on it for everything. That's not to say, however, that I never use the built-in Neovim :terminal.

I thought it might be easier to only ever have one buffer open for a given file, instead of attempting to open a file in a given pane only to realize that it's already open in a different neovim instance

This is not a problem in my config:

    vim.api.nvim_create_autocmd({ 'FocusGained', 'BufEnter', 'CursorHold' }, {
      pattern = '\*',
      command = 'silent! checktime',
    })

I've been keeping an eye on this in the hopes that text-reflow (edit: including for scrollback) could be solved in Neovim-based terminals [1]. I'm loving the innovation Ghostty is bringing to the terminal space.

1. https://github.com/neovim/neovim/issues/33155

This is what I love HN for. "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should".

This awakens things I've been thinking about Neovim for a while now: now that libuv is embedded, there's really no reason not to use it as a cross-platform application runtime (except for the fact that that's horrific).

It's linked above (https://github.com/opencode-ai/opencode)