There was onivim that was a bit hyped a few years ago but unfortunately it died
The vi family
51–60 of 198 posts
Re: The vi family
#52The history and endurance of vi is impressive. I never thought I would be using the same editor today that I started using in the mid 90s because it was more l33t. The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
The inclusion of comments about LLM generated code don't bother me and will probably be quite revealing (for better or worse) when people read this post in the future.
Also, I have not been following the d2d development of vim closely after Bram's passing but I can't help but wonder what he'd have thought about this approach to development of vim.
Re: The vi family
#53It’s funny how many forks aiming to keep it free from LLM-generated code. The luddites are present even in the most progressive parts of the population.
vi was never progressive, it was "the Ancients knew it better, the present sucks, these kids have terrible taste, return to the one true Past"
The Ancients did know it better.
I sometimes try working without vim keybindings as it's a pain installing them everywhere. I usually give up the 3rd time I have to delete a function argument and can't dt, or select the body of a function and can't vi{.
For everyone even somewhat decent at vim, having to hold right arrow until the cursor reaches the target is a humiliation ritual, and I genuinely feel second-hand embarrassment and pity when I see people do that.
Re: The vi family
#54Few days ago I watched a video where a guy wrote the code for Linux USB driver from scratch. In frickin' vi! It was a ride
And he doesn’t use any config it seems. No syntax highlighting, no line numbers, plain white text on dark background.
Exactly, it's wild!
If anyone wants to have a look: https://www.youtube.com/watch?v=IXBC85SGC0Q
Correction, the driver is specifically for Apple Xserve front-panel
Re: The vi family
#55I think describing Kakoune/Helix as vi-inspired with “slightly different keybindings” is rather missing the point.
The most important difference is that they invert the editing model from verb-noun to noun-verb. Meaning you always see exactly what you’re going to be operating on before you do it.
The second most important difference is that they were designed from the ground up around multi-selection editing as a primitive, rather than a plugin or late addition.
That model is typically less efficient purely in terms of keystrokes, for some operations significantly so, but it’s somewhat mitigated if having the state on-screen rather than in your head means you undo less often.
I wouldn’t suggest either approach is superior. I suspect most people (“most people” in the subset of people who jibe with modal editing to begin with, anyway) will find that one just fits their brain better than the other.
Personally, even having used Vim almost daily since finding it on a Fish Disk sometime in the mid-90s, I still turned out to be in the kak/hx group. I can still use vi quite comfortably when I need to, but Helix removed a bit of friction I’d barely been aware of.
There’s a steady stream of NeoVim exiles to Helix forums, I think who mostly found its Lua-based config too complex/brittle, asking why the devs don’t add settings to make it work like Vim, include a *Vim keymap as standard, etc.
It’s kind of wild to me that people would choose their editor based on how minimalist its config/how batteries-included it is, rather than its fundamental editing paradigm.
Re: The vi family
#56Interesting that there is such a clearly stated differentiation between projects that use "LLM-generated code" and those who don't.
I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
Re: The vi family
#57Earlier quoted context omitted.
vi was never progressive, it was "the Ancients knew it better, the present sucks, these kids have terrible taste, return to the one true Past"
The Ancients did know it better. I sometimes try working without vim keybindings as it's a pain installing them everywhere. I usually give up the 3rd time I have to delete a function argument and can't dt, or select the body of a function and can't vi{. For everyone even somewhat decent at vim, having to hold right arrow until the cursor reaches the target is a humiliation ritual, and I genuinely feel second-hand emb…
allow me to quote the Ancients, the vi creator himself:
> What would you do differently?
> JOY: I wish we hadn't used all the keys on the keyboard.
> ...
> JOY: The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In some sense, its backwards from the kind of thing you'd get from a mouse-oriented thing.
> Its like one of those pinatas - things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back - I wouldn't go back, but start over again.
shots fired:
> JOY: I can just look at my screen, and when I print it off, it's the same as it looks on the screen. It is formatted, and I'm tired of using vi. I get really bored. There have been many nights when I've fallen asleep at the keyboard trying to make a release. At least now I can fall asleep with a mouse in my hand. I use the Xerox optica mouse instead of the other one because it is color coordinated with my office. Did you notice? I prefer the white mouse to the black mouse. You've got to have some fun, right?
Re: The vi family
#58The first work i had to use vi and screen on a terminal, it were in 90s . I was used to dos editors ( edit, turbo C ... ) and windows . It was a pain. copy and paste at first was a nightmare. Copy from one file to another ,with named register and # was an hell ( it was vi not vim so only 2 files a time ,the actual edited and the prior ones ). I hated that place, that work, those tool for a while . I got so used to vi, to modify columns with regular expression or macro that now, more than 30 years after , vi/vim is the first thing I install on a PC and when i have to modify a file, or to do something complex, the first and last resort for doing it without python or perl, is always vi . But the beginning at 25 years old was very hard because it was a kind of editing even at those time completely out of my usual way to work . Now it is the only editor that i open and use without thinking . VSCode is great, tons of features, but when i see all those menu, if i can, i use vi . I would add a point. for a while i went behind vim features, try to learn them and use them but they are too many and i often work on different machine so i can not move my setup everywhere. Learning the "old vi way" of doing things (motion, regexp,registers, macros ) can seem "limiting", but at the end you can do quite everything with the same tool .
Re: The vi family
#59Interesting that there is such a clearly stated differentiation between projects that use "LLM-generated code" and those who don't. I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
Pretty well if you consider the "bio" label, which is a set of practices not using all of the tech. They can ask for and usually get higher prices for the products.
Granted, it's more about chemicals than tractors, but still quite close to the spirit of the comments. Bio approach sacrifices some tech advances.
Re: The vi family
#60Interesting that there is such a clearly stated differentiation between projects that use "LLM-generated code" and those who don't. I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
Early tractors were attempted in 1800s but most farmers ignored them as they were complex, expensive and occasionally exploded[1].
Sounds familiar.
[1]: “However, even though steam-powered tractors provided an alternative to draft animals, the size, mechanical complexity and risk of explosion rendered these tractors unusable for most farms.” https://www.volocars.com/blog/history-of-tractors-in-agricul...