Vim: Clearly evil, lightning fast. Relies on vimscript for any interactivity and can barely be used outside of the editor.
Emacs: the hippie brain child of some of the brightest minds at the MIT AI lab, funded by military contracts. Slow, but uses a near-universal language that can easily escape the bounds of the editor, (and often does (, and holy shit where did those parentheses come from. (Oh no, it’s becoming self-aware… fly you fools!
Vim: Clearly evil, lightning fast. Relies on vimscript for any interactivity and can barely be used outside of the editor.
I don’t know why you want use Vimscript for anything outside of the editor. But if that your issue, then there is Neovim. It uses Lua instead Vimscript, but what is the benefit of using Lua outside of Vim? That changes nothing.
Lua outside of Vim has huge applications in embedded products. Dude I would kill for Lua. Do you know what we have? Common Lisp. Yeah, it’s great and fancy and all, but try adding that to your CV and applying for an embedded system job.
My point is, then use Lua outside of Vim. What does this have anything to do with the language used in Vim? You can use Vimscript in Vim, and still use Lua outside of Vim. So what’s the problem? It’s not like Lua gets available to you outside of Vim, just because you switch to Neovim. What do I miss here?
(it was mostly a joke, but) the skills you acquire tinkering your Vim to your needs using vimscript can’t be used elsewhere, whereas Emacs has the (small) advantage that at least most of one’s elisp skills can be translated to common lisp quite easily (with the joke being that common lisp really isn’t that useful, hence my Lua jealousy rant).
It’s not fun when you have to explain it. But basically it is based on the infinite multiverse theory. Since the multiverse splits whenever you make choices, in this case the program would spawn a large number of multiverses each with different combinations of those bits, which means at least one of them would have the exactly the combination we want. If the program destroys the multiverse it is in after it determines it is not correct, only reality that remains is the one with correct combination of bytes. Making it that we will get the code we want on the first try.
You are assuming here that I know what I want. What if there is no obviously correct answer, and even in the Everett branch that generates the optimal content for the file I’ll still think it can be improved and tell it to destroy the universe?
I guess yeah. In that condition the algorithm would probably destroy all universe. Although you might be able to set a threshold and not destroy when it is over the threshold.
But situation where you don’t know the answer is not for this algorithm as this one came from sorting problem.
Isn’t this supposed to be VIM vs Emac? What’s is there point to be programming in the terminal anyway? Nano is good to fix some config files while your are in there, but if I needed to do real programming I’ll be finding something that works in the GUI.
Oh it’s about speed. What’s the one that get your brain to be faster at programming? I use 4 fingers typing and am still typing much faster than I can think.
Definitely worth running through vim tutor at least once.
It’s beyond typing speed, things like piping out strings to utilities is using one program to write another, you aren’t just getting faster because of access, it’s a paradigm shift.
Edit just for fun: im a non Dev dummy who happened to grow up in a Unix household. Even having dropped vim for helix and bounced around the MS admin/Apple IT space for 30+ years. When I switched to Linux I could still remember binds I’d set up and last used at 9.
It’s speed, but it’s also flow and a continuous stream of thought. If all your editing is being done with muscle memory and minimal thought, you can continue thinking about the problem at hand rather than interrupting your thoughts process to fumble through some context menu to make a change.
lemmy.fosshost.com
Active