Indeed, if you're running the db in production and aren't using TLS, you're doing it wrong nowadays. Nearly every compliance framework will require it, and it's a very good idea anyway even if you don't care about compliance.
This is the perennial argument that IMHO is based on a fallacy. If the vim people suddenly stopped working on vim, it doesn't mean all their effort would go to neovim. People work on what they want to work on in open source. Also the two projects have very different goals/philosophies. The code bases have also gotten pretty different in architecture because neovim did a monstrous refactor. It's open source working as intended that we have both.
One little thought is, has there been much drama between the vim and neovim communities? (I guess community can be defined broadly enough that the answer to that question is always “yes,” but I haven’t seen much). They both seem completely happy to just do their own thing. I think the perennial argument just exits in the mind of some fans.
It is nice to see a pair of projects with so much potential for competition coexisting peacefully. Plenty of room on the internet I guess.
> That said I'd have preferred something other than Lua if I had the choice.
Same. I know we as a community would never agree on what that language should be, but in my dreams it would have been ruby. Even javascript would have been better for me than Lua.
Lua, especially with LuaJIT, is nearly as fast as C. I certainly don't want to have to run a slow language like Ruby or especially a full blown JS runtime like V8 just to run Vim, the entire point is speed and keyboard ergonomics, otherwise just use VSCode.
Because I know javascript a lot more than I know Lua (and I suspect given js popularity, a lot of people are in the same boat). Yes Lua is easy to learn, but it's still different enough that there is friction. The differences also aren't just syntactically, it's also libraries/APIs, and more. I also don't have any need/use for Lua beyond neovim, so it's basically having to learn a language specifically for one tool. It's not ideal for me.
But the people who did the work wanted Lua, and I have no problem with that. That's their privilege as the people doing the work. I'm still free to fork it and make ruby or js or whatever (Elixir would be awesome!) first-class.
I agree but also wonder if editor plugins fall squarely in the range of things an LLM could vibe-code for me?
There is a large class of problems now for which I consider the chosen programming language to be irrelevant. I don't vibe code my driver code/systems programming stuff, but my helper scripts, gdb extensions, etc are mostly written or maintained by an LLM now.
i’ve written probably north of a million lines of production js, maybe around 100,000 lines of production ruby, and about 300 lines of production lua. lua is a fun language and i think a much better fit than JS for technical reasons (who has a js engine that is both fast and embeds well? nobody), but i am certainly more productive in those other languages where i have more experience.
lua array index starting at 1 gets me at least once whenever i sit down to write a library for my nvim or wezterm.
Hell yeah, this is some badass hackery, and the type of stuff I love seeing on HN. In the last decade or so as more and more stuff becomes locked down and hacker unfriendly, I've found myself longing for simple things I can hack on. If I ever get to a point where I don't have to work for a living, one of the things I'd like to do is build everything from little gadgets up to major appliances that are simple, reliable, and hackable for people who want to. It pains me that my appliances have full computers driving them but I can't get access to them. Kudos for this awesome work and phenomenal write-up!
Really neat! Also as a Linux user, I deeply appreciate the linux support :-)
A few questions and comments:
| Kvile |
- Awesome, really happy to see a reasonable take on this (open source, offline-first, no telemetry, no acount, etc). Do you think at some point you'll try to monetize it in some way?
Kvile: Thanks for letting me know! havent noticed, since i mostly just use it myself. Will get it fixed!
Stao: Hm yea this is a mistake on my LLM when it generated the website for me (i couldnt be bothered). It probably got confused since i released it for Linux. Its not open-source. Yes! Exactly, thats why i made it, i ALWAYS forgot. I still do, but far less frequently than before, using Stao helped me a lot.
Looks like a neat tool, and one I really need! I actually started building my own because I couldn't find anything satisfying. My build is currently in the very early stages and I'd love to abandon it :-) I'm definitely going to try difi out.
Also kudos for putting up a screenshot. I've looked through a lot of projects claiming to do similar to this, but there are so many different interpretations that can make it not a good fit for me, and when there aren't any screenshots the barrier of seeing it in action is often too high to where I only try one or two before I give up and stop wasting time. Having a screenshot made it so I could check it out quickly.
The screenshot is a little rough, so a few tips for next time:
1. Shrink your terminal window down a bit as a huge view is harder to follow
2. Keep the screenshots at full resolution so they are easier to read. The reduced resolution and the original screen being huge makes the text pretty difficult to read, even zoomed in to 200%
3. Use something like screenkey (or throw some subtitle text up or something) so the viewer knows what keys you are pressing and/or what you're trying do. It's pretty hard to follow along without those cues.
just my experience of course, but it had a lot of hype. It got into a lot of people's workflow and really had a strong first mover advantage. The fact that they supported neovim as a first-class editor surely helped a ton. But then they released their next set of features without neovim support and only (IIRC) support VS Code. That took a lot of wind out of the sails. Then combined with them for some reason being on older models (or with thinking turned down or whatever), the results got less and less useful. If Co-pilot had made their agent stuff work with neovim and with a CLI, I think they'd be the clear leader.
Yeah, you may have nailed it. Gemini is a good model, but in the Gemini CLI with a prompt like, "I'd like to add <feature x> support. What are my options? Don't write any code yet" it will proceed to skip right past telling me my options and will go ahead an implement whatever it feels like. Afterward it will print out a list of possible approaches and then tell you why it did the one it did.
Codex is the best at following instructions IME. Claude is pretty good too but is a little more "creative" than codex at trying to re-interpret my prompt to get at what I "probably" meant rather than what I actually said.
Can you (or anyone) explain how this might be? The "agent" is just a passthrough for the model, no? How is one CLI/TUI tool better than any other, given the same model that it's passing your user input to?
I am familiar with copilot cli (using models from different providers), OpenCode doing the same, and Claude with just the \A models, but if I ask all 3 the same thing using the same \A model, I SHOULD be getting roughly the same output, modulo LLM nondeterminism, right?
I've had the exact opposite experience. After including in my prompt "don't write any code yet" (or similar brief phrase), Gemini responds without writing code.
reply