_7tgr

Right, input latency is what matters for me. I'm not seeing whether they've measured that in the docs/on Github.

Yes, it constantly bugs you about buying OneDrive.

To be honest I've never had issues like you're describing and I've been using Linux nearly exclusively as a desktop OS since the 2010s. The main deficiency is that it doesn't have eg a good Photoshop alternative, but what's there works well-- and these days the browser has supplanted most native proprietary software, anyway. Things have only broken for me when I've hacked/customized them to the point that it's a miracle they work at all.

OTOH, Windows has never given me anything but trouble... stuff that's easy on Linux semi-frequently required regedit hacks. I remember having to mess with some DCOM thing and ended up hosing my Windows install. Not to mention that it's awfully slow without installing a bunch of debloating tools (and even then...).

Yes I'm waiting for a nixos package. I have used it a bit through the Docker image and it's super cool. I can see it succeeding emacs. Seems like it's even more hackable than the latter, since it's all written in Common Lisp (there's no C core).

Yeah, that was mostly my thinking. I like lisp!

I mentioned speed because they're writing their own instead of using Chez or Gambit or something (which have taken a while to get into 'performant' territory). Writing and maintaining a fast(!) Scheme is hard. Having spent time with r5/r6/r7rs (many variants for the latter) and their quirks I'd honestly say Lua is simpler by a wide margin, but some of this is down to preference. The Lua execution model, if nothing else, is a lot easier to understand than call/cc for instance. And the language does force you to write things functionally, practically speaking. I'm also not a huge fan of syntactic macros. Also things like dynamic binding which, in fairness, are just SRFIs but end up being implemented by most Schemes. I do respect their willingness to do what's fun for them, though :) that's what it's all about.

I think a big missing piece with writing what you want in Rust and recompiling the editor to activate your changes is that you're not able to work with it _live_. That is, I can use the vim (or nvim or emacs) GUI/text processing/IO/etc facilities interactively as I'm writing my snippets to see if everything works the way I expected. I can send lines/expressions to the lua/elisp compiler running in the editor that I'm _currently using to write the program_ to change how it works, _on the fly_. It's an integrated programming experience in a way that very few things are--- it's not just about programmability, but this circular thing that goes on with editors that really fully commit to it.

Yeah, I was on the nightly release (via nix) for a while. Rock solid.

Echoing the other replies here that idk what breakages this refers to. I switched since I liked lua better than vimscript (after writing a ton of vimscript). I don't use many plugins; the few I use haven't broken. Only encountered a single (non-serious) nvim bug that wasn't also a vim bug in many years of use.

Agreed. I've been using (n)vim for roughly 8 years now and only touch my config to put in bits of Lua I've hacked together to make my life slightly easier (~10 minutes every few months? I just do it as-needed). I use 5-6 plugins total. I think the most vocal users are probably responsible for the impression of constant churn, because they've got fancy tricked out configs loaded with alpha-quality plugins and probably do need to constantly update it. Nothing against doing that, but it need not be that way!

And, oddly, they chose to do their own Scheme implementation for it. Not that I'm against Scheme in particular, but a lot of other people justifiably seem to be. It doesn't have the speed or learn-it-in-10-minutes of Lua (nvim) or the historical excuse of Elisp/Vimscript (emacs/vim) or the ecosystem of Typescript (vscode). Strange choice.

I think you only miss (or at least I noticed this happened to me) a plugin system when you've engaged with the programmable side of your editor and then have to use one that isn't. I dont use/try to stay away from using (neo)vim plugins but I do like to pull out repetitive things into little snippets. I have things to manage my clipboard, pull up manpages in another editor tab when I put my cursor over a command and press a key in terminal mode, and a scattering of other quick useful tools. A lot of it's not reasonable to upstream, so it's a bit frustrating to me personally to use stuff that isn't programmable.

I've also toyed with emacs in the past and think I could like it for this reason, but ironically most other programming editors don't seem to be committed to the user's abilities as a programmer. I don't think it's nearly as easy/accessible/encouraged to program vscode, for instance. Self-documenting programmable programs like vim and emacs are so magical--- I hope they never go out of fashion.

This does not seem like a standard way to conduct business to me by any stretch of the imagination, though I don't work in cybersecurity. Perhaps that community just has lower standards to which people and organizations are held. Would not be surprised. The things I've heard from that corner of the industry....

I don't know, but it's been more reliable for me than /bin/bash. I think env is part of POSIX.