101–110 of 198 posts
Few 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.
I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient, since they were developed to work accross a broad range of UNIX systems (SCO, Solaris, HP-UX, OSF, AIX) and I rarely add anything to my vim configs on top of that other than syntax highlighting. But I'd still rather use it than just about any other text editor, just for the simplicity of that muscle memory alone. I have…
I think that it's wrong to assume that vi is the only route to deep muscle memory. Heavy mouse users develop blindingly fast Fitts’ Law targeting. And if you need essential simplicity, they have far fewer commands. Bill Joy, the original author of vi, saw the vi commands as a problem, not a solution [1]: The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In so…
Even if you remember the general placement of things? You still have to consciously track where the pointer is and when it will be on target. I was better with old applications where everything was accessible, bit in this era of low density interface and deep navigation, it’s not great.
The Acme editor is a great example on how to use the mouse. Every click results in an action. And a customizable interface so that you can have what you need at the ready.
I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient, since they were developed to work accross a broad range of UNIX systems (SCO, Solaris, HP-UX, OSF, AIX) and I rarely add anything to my vim configs on top of that other than syntax highlighting. But I'd still rather use it than just about any other text editor, just for the simplicity of that muscle memory alone. I have…
But I made the switch to nvim / LazyVim. And it is actually pretty good. I had in mind those endless hours of config and lua scripting. At the end of the day all I needed actually was to remove a plugin (folke, which messes with my 's' key) and learn to use the package manager to setup the languages I wanted.
Having things like GrugFAR or lazygit at the tip of my finger is actually a quality of life improvement. I could do without those for sure but they fit my workflow and muscle memory well.
Still wish there was something better for ansible ; I should have gone with pyinfra with my current job's project but I only learned about it after writing 12k LoCs of ansible :'(
The 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.
I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient, since they were developed to work accross a broad range of UNIX systems (SCO, Solaris, HP-UX, OSF, AIX) and I rarely add anything to my vim configs on top of that other than syntax highlighting. But I'd still rather use it than just about any other text editor, just for the simplicity of that muscle memory alone. I have…
Earlier quoted context omitted.
> I have way more stuff to keep in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a text editor. I can't say I agree. To me this is equivalent to saying "I have way more music in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a piano". The tool you use for 8+ hours a day is extremely important and even small gains will p…
To continue the musical instrument analogy, I already master the piano and I am happy with it solving my requirements. Learning the guitar will be a great undertaking, and provide me no new songs to play. Hence, I will stick to my piano.
cool stuff, for a bunch i didnt realise they were really distinct versions! Use Helix now as the first one that stuck in my fingers though. before that it was always try a lil while and forget it (back to nano...). Helix i think is like 'user friendly vi' or maybe 'no config vi'. dont need any plugins or weird stuff. everything essential works out of the box (for me)
I really want to use Helix, it clicks with me so much more. But I do not want to learn how to use Helix for development. I want to be able to continue using VSCode. And last I checked, the VSCode extension was not very good. I also use Vim keybindings in Obsidian. The moment VSCode and Obsidian support improves, I am switching immediately.
The 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…
I actually learned VI using DOS and the Watcom C/C++ compiler and 32 bit dos extender, as it included a vi clone. Maybe it should be included in the list. It can still be downloaded from the openwatcom project, https://openwatcom.org/ftp/manuals/1.5/vi.pdf
Earlier quoted context omitted.
> I have way more stuff to keep in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a text editor. I can't say I agree. To me this is equivalent to saying "I have way more music in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a piano". The tool you use for 8+ hours a day is extremely important and even small gains will p…
He IS saying that. Vi is more efficient for him every hour every day because he has been able to learn it to the point where there is nearly zero effort in using it. To learn something else would be to throw away all that hardcoded memory and try to rebuild it.
I never made that switch. The muscle memory of 2 decades of using a software is under appreciated.
For me, it is about preference for what to optimize for.