Live data from Hacker News

Why I teach vim

blog.ceos.io

11–20 of 185 posts

Re: Why I teach vim

#11
post #7
post #5

Earlier quoted context omitted.

I'm not sure about the specifics, but providing something a lot more "batteries-included" seems to be the idea behind Emacs distributions like Spacemacs and Doom Emacs. One difficulty is that language-specific tools (language servers, linters... etc) are standalone pieces of software with their own dependencies, requirements... etc. It's hard to bundle together a fully "batteries-included" Emacs without figuring out…

Emacs mostly has problems with external language servers because its plugin model is archaic and brittle to a large extent compared to that of say VS Code. It's also far more flexible but with power comes responsibility, and I've found Emacs extensions far more likely to interfere with each other than in less composable editors. You don't need Nix to fix this problem.

Given the brittleness there should be at least a single configuration that works. I believe that tikhonj is right in the sense that nix can capture this configuration. Nix is not required but I can see how it can help.

Re: Why I teach vim

#12
> I always tell my students that the one editor they are likely to find already installed on a machine is vim

Well, vi, since it's part of POSIX. Unless you are fine with ed ;)

Re: Why I teach vim

#13
post #5

Earlier quoted context omitted.

I'm not sure about the specifics, but providing something a lot more "batteries-included" seems to be the idea behind Emacs distributions like Spacemacs and Doom Emacs. One difficulty is that language-specific tools (language servers, linters... etc) are standalone pieces of software with their own dependencies, requirements... etc. It's hard to bundle together a fully "batteries-included" Emacs without figuring out…

I'm positive some sadist somewhere in this world has all the software on their OS as a nix expression. I'm also positive that at least one of these people has a fully featured emacs IDE and all the required dependencies as part of that expression. Totally down to try it if anyone has it. One thing good about just standalone vim though is how portable it is. I can ssh into any server and fire it up. I also want this f…

funnily enough it's something I've been working on for my personal dotfile setup but instead unfortunately decided to go with ansible for now despite being a big fan of both nix and nixos. Nix was just a bit too heavy for some of the small lxc containers etc I wanted to setup.

Re: Why I teach vim

#14
post #8

"I wish I could say I agonized over all the options at the time and decided vim was the best pedagogical solution, but the reality of the situation was that vi was what I used in college because my father taught me vi" We dont talk about this much, but many of us hardcore Vi/Emacs users have had this knowledge imparted to us from a mentor. Thats probably why the use of Vi/Emacs is much higher in established tech envi…

They're not really the same thing, compared to vi[m], emacs is statistically dead. And there are already lots of people who're well into their careers in academia and industry who aren't users of either.

My own contrarian and probably equally wrong take is that it's mostly about accepting the (evidence-free) premise that modal editing is actually a good thing. It's hard, you suffer but lots of smart people tell you it's worth it and perhaps your suffering will help you be as smart as them. It ends up being closer to hazing and penance (your editor as hairshirt) than actual gatekeeping.

Re: Why I teach vim

#15
post #10
post #6

Earlier quoted context omitted.

Ya that would be really helpful. I've picked up bits and pieces of vim over the years. Recently, I even installed vimium on Chrome and the vim extension for VS Code in an attempt to get better at it. It has been quite effortless to delete or replace words or lines but every time I've tried getting more adventurous with it - say, surround every line of text with double quotes etc, I end up finding the commands unintui…

I guess I’ve got used to working with both sets of shortcuts but I miss the Vim undo system in other apps. It’s worth noting that u and ctrl-r don’t operate on an undo stack but on an undo tree. So if you have a series of edits and undo them all then do something else you can still get back to where you were before. Use g+ and g- to walk the tree and the Gundo plugin is gives you a nice visual diff interface. So havi…

Wow I didn't know about the undo tree! That would have definitely helped in a few scenarios

Re: Why I teach vim

#16
post #10
post #6

Earlier quoted context omitted.

Ya that would be really helpful. I've picked up bits and pieces of vim over the years. Recently, I even installed vimium on Chrome and the vim extension for VS Code in an attempt to get better at it. It has been quite effortless to delete or replace words or lines but every time I've tried getting more adventurous with it - say, surround every line of text with double quotes etc, I end up finding the commands unintui…

I guess I’ve got used to working with both sets of shortcuts but I miss the Vim undo system in other apps. It’s worth noting that u and ctrl-r don’t operate on an undo stack but on an undo tree. So if you have a series of edits and undo them all then do something else you can still get back to where you were before. Use g+ and g- to walk the tree and the Gundo plugin is gives you a nice visual diff interface. So havi…

This is really cool, and I had no idea about Vim using a tree instead of a stack for undos. I'll check out Gundo.

Do you have any other similar recs that would help for learning?

Re: Why I teach vim

#17
post #5

Earlier quoted context omitted.

I'm not sure about the specifics, but providing something a lot more "batteries-included" seems to be the idea behind Emacs distributions like Spacemacs and Doom Emacs. One difficulty is that language-specific tools (language servers, linters... etc) are standalone pieces of software with their own dependencies, requirements... etc. It's hard to bundle together a fully "batteries-included" Emacs without figuring out…

I'm positive some sadist somewhere in this world has all the software on their OS as a nix expression. I'm also positive that at least one of these people has a fully featured emacs IDE and all the required dependencies as part of that expression. Totally down to try it if anyone has it. One thing good about just standalone vim though is how portable it is. I can ssh into any server and fire it up. I also want this f…

"the editor becomes the ssh client itself" is effectively how I use Emacs. TRAMP (https://www.emacswiki.org/emacs/TrampMode) makes editing remote files pretty much as seamless as editing local ones. I even semi frequently do slightly-crazy-seeming things like open files via chains of several ssh hops and I can "save" them (read: marshal a complex operation involving scp, base64, and other sourcery) in exactly the same way I can save something to the home directory on my workstation. TRAMP is a default part of the Emacs distribution (and has been for over 10 years), so it doesn't require installing extra packages or even enabling anything. It's just on by default.

This capability, plus "frame" management commands and the various terminal modes make my use of Emacs roughly equivalent to they way I see colleagues (I'm an ops/sysadmin type, not really a developer) using vim + tmux.

Re: Why I teach vim

#18

I really wish there was a batteries included vim-like console editor with all the power of the jet brains suite of IDEs and convenience and lightness of vim. As it stands right now I end up using both an IDE and vim. Maybe emacs is the answer but honestly if I look past all the yak-shaving to get emacs to the power level of an IDE does it really get to the point where it has everything that say CLion has?

I too tried spacemacs and loved the initial 30 minutes. And then I wanted ESLint, and maybe even TabNine for autocompletion. After several hours looking up random gist files I gave up. I don't get paid to edit lisp configs to get my IDE to the usability level of the one my company already pays for (IntelliJ). It's a real shame, but I just don't have the time or energy to deal with those configs.

Re: Why I teach vim

#19
post #14
post #8

"I wish I could say I agonized over all the options at the time and decided vim was the best pedagogical solution, but the reality of the situation was that vi was what I used in college because my father taught me vi" We dont talk about this much, but many of us hardcore Vi/Emacs users have had this knowledge imparted to us from a mentor. Thats probably why the use of Vi/Emacs is much higher in established tech envi…

They're not really the same thing, compared to vi[m], emacs is statistically dead. And there are already lots of people who're well into their careers in academia and industry who aren't users of either. My own contrarian and probably equally wrong take is that it's mostly about accepting the (evidence-free) premise that modal editing is actually a good thing. It's hard, you suffer but lots of smart people tell you i…

> it's mostly about accepting the (evidence-free) premise that modal editing is actually a good thing.

Kakoune's development has started fairly recently. The oldest tags on its GitHub repo are for 2018. I think this defies "people want to continue the legacy of actually-not-that-great thing because I had do suffer, so other people should too". I think you'd only put into making/promoting Kakoune if you genuinely thought modal editing is a good thing.

Whereas, if the bigger value in "I learned modal editing" is the signal of "modal editing is hard, so anyone who knows it must be good" (rather than value from a better developer experience), I think aiming to make modal editing more intuitive/accessible is counter-productive.

Re: Why I teach vim

#20
post #7

Earlier quoted context omitted.

Emacs mostly has problems with external language servers because its plugin model is archaic and brittle to a large extent compared to that of say VS Code. It's also far more flexible but with power comes responsibility, and I've found Emacs extensions far more likely to interfere with each other than in less composable editors. You don't need Nix to fix this problem.

Given the brittleness there should be at least a single configuration that works. I believe that tikhonj is right in the sense that nix can capture this configuration. Nix is not required but I can see how it can help.

Nix would be useful for a description of the non-Emacs dependencies. Particular versions of the compiler and LSP program. -- Some languages are more fickle about this than others.
Post reply on HN