You can roll a script to do this, something that would consume a mic from Pipewire when triggered and then push results to clipboard. With a Parakeet ONNX model in between.
I had cause to do the the opposite: Hotkey -> clipboard TTS
My ~1.7% WER and faster than realtime processing in my application make it more than adequate. My application is multi-speaker with WPM rates >300 for long durations.
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.
You don't need V8 for running JS for scripting, you have quickjs[1] or mquickjs[2] for example. You might have problems importing npm packages, but as we can see from lua plugins you don't even need support for package managers. Performance is not as good as luajit, but it is good enough
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'm right there with you, and to be honest Lua just works. I helped with Neovim when it started ~10 years ago, and didn't understand the big deal about implementing lua.. But now that it's here, I can't believe it wasn't forked and implemented sooner
IME, Claude is quite good at generating Lua code for neovim. It takes some back and forth because there's no easy way for it to directly test what it's writing, but it works.
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.
reply