Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I teach vim

blog.ceos.io

Post reply on HN
Print view View original

171–180 of 185 posts

Re: Why I teach vim

#171

Post by gen220 »

greggman3 wrote: post #167
gen220 wrote: post #112

Earlier quoted context omitted.

From my perspective there are two sticky elements to vim, where once you’re accustomed to exploiting them, you find it very difficult to leave. The first (chronologically speaking, for most people) is modal editing. Most popular editors today support vim bindings. So this bulwark is gradually eroding. The second is the automation. Any piece of your workflow can be captured and remapped to a couple keystrokes. Some ot…

> Any piece of your workflow can be captured and remapped to a couple keystrokes How is different than recordable macros in 90% of the other editors out there? (vs programmable macros). Can you give me an example you use regularly

Sure! One example is vim-dispatch, which provides a convenient interface for executing arbitrary shell commands asynchronously.

It works wonderfully with make, so you can run “make $file” in a couple strokes. I use this when writing markdown (to generate html with pandoc), editing test files, etc.

Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times. You could do the same thing with a regex sometimes, but for really complicated files this is easier.

A final, simpler one: I have f mapped to fd piped into fzf piped into open. Other editors probably have fuzzy file finders. Some of them maybe even use fzf internally.

But I think this example demonstrates how vim embodies UNIX ideas, as a modal text editor that depends on other binaries for complex behavior. People levy this as a complaint, that it doesn’t come feature complete, but it’s in reality a strength. Because while other editors wax and wane in terms of features and performance, vim only ever gets faster, as the binaries you depend on are swall out for better replacements every couple years.

Re: Why I teach vim

#173

Post by pampa »

lazyant wrote: post #169
pampa wrote: post #43

Earlier quoted context omitted.

I suffer every time a linux distro has nano as the default editor. Cant save a file, cant exit, have to read the two bottom rows and figure out those alien shortcuts. yuck

Those alien "shortcuts" are Emacs bindings, the same as in a Bash shell, or a Cisco router etc.

I did use emacs before i switched to vim 15 years ago. My memory is hazy, but i am pretty sure Ctrl-O to save a file and Ctrl-X to exit are not emacs bindings. I was as confused with nano when i used emacs as i am now.

Re: Why I teach vim

#174

Post by lazyant »

pampa wrote: post #173
lazyant wrote: post #169

Earlier quoted context omitted.

Those alien "shortcuts" are Emacs bindings, the same as in a Bash shell, or a Cisco router etc.

I did use emacs before i switched to vim 15 years ago. My memory is hazy, but i am pretty sure Ctrl-O to save a file and Ctrl-X to exit are not emacs bindings. I was as confused with nano when i used emacs as i am now.

yes, some bindings may be different for meta-control like you are pointing out (the editing ones are Emacs)

Re: Why I teach vim

#175

Post by HowTheStoryEnds »

alvarosevilla95 wrote: post #104
greggman3 wrote: post #100

Earlier quoted context omitted.

I am curious if any vim user has ever been able to see the benefits of other environments. I know I have never been able to see the benefits of vim. Part of me wants to give a try for 3-6 months just to prove to myself that it's all bullshit and that vim is just another editor. In any case. For a long time I was a fan of my editor of choice, slickedit. It definitely has a few features I use for which I don't know the…

You should read about the language server protocol. As it continues to become the standard vim will match most IDE-specific features while keeping all the benefits of using vim, which if you can't see I won't bother listing here. I'm already working on java 100% from vim and I don't miss a thing from intellij

Would you mind elaborating a bit on that for those of us not in the loop, like myself? Which plugins are you using?

Re: Why I teach vim

#176

Post by tomhoward »

tomhoward wrote: post #164
bitcoinmoney wrote: post #102

Earlier quoted context omitted.

Link to the cheat sheet and coffee mug?

Here it is [1]. I just found it in the back of my crockery cabinet! Looks like it's stayed in amongst my possessions for the nearly 20 years since I got it, through several house moves and stints in storage. It's going back on my desk now. I can't find any the same as this when searching for it online now, but this seems the closest [2]. I like the simple text design much more than the coloured keyboard layout [3]; m…

BTW I've just remembered that the mentor who introduced me to Vi was also the person who told me I should switch from AltaVista to Google. Heady days.

Re: Why I teach vim

#177

Post by greggman3 »

gen220 wrote: post #171
greggman3 wrote: post #167

Earlier quoted context omitted.

> Any piece of your workflow can be captured and remapped to a couple keystrokes How is different than recordable macros in 90% of the other editors out there? (vs programmable macros). Can you give me an example you use regularly

Sure! One example is vim-dispatch, which provides a convenient interface for executing arbitrary shell commands asynchronously. It works wonderfully with make, so you can run “make $file” in a couple strokes. I use this when writing markdown (to generate html with pandoc), editing test files, etc. Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, an…

Unfortunately I'm not understanding what makes vim special here

> It works wonderfully with make, so you can run “make $file” in a couple strokes

I can do this in any editor I've ever used

> Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times.

I can do this in most editors I used (VSC being an exception). I use recordable macros all the time to clean up lines in emas or slickedit or any other editor that has recordable macros

> A final, simpler one: I have f mapped to fd piped into fzf piped into open. Other editors probably have fuzzy file finders. Some of them maybe even use fzf internally.

Can do this in every editor I've ever used too.

Any actual vim only examples?

Re: Why I teach vim

#178

Post by greggman3 »

camgunz wrote: post #160
greggman3 wrote: post #100

Earlier quoted context omitted.

I am curious if any vim user has ever been able to see the benefits of other environments. I know I have never been able to see the benefits of vim. Part of me wants to give a try for 3-6 months just to prove to myself that it's all bullshit and that vim is just another editor. In any case. For a long time I was a fan of my editor of choice, slickedit. It definitely has a few features I use for which I don't know the…

I'll bite; I'm real good w/ Vim. My thesis, which is a borderline polemic, is that if Vim doesn't suit your needs you are doing it wrong. If your program/language/environment needs a smart editor, you've built or chosen a program/language/environment that is too complex, and an IDE won't ever solve that fundamental problem. I get we don't always get to choose these things (wh o hasn't had to learn React, Typescript,…

hmmm, if I apply that logic in other places it doesn't seem to work.

* if you can't cook with just a knife then it your food should be redesigned to need only a knife.

* if you can't film in with a camera then you should rewrite your movie (no CG).

* if you can't send it by paper then it should be re-written (no animation, no interactive diagrams, no apps)

To put it another way, I'd much rather use Final Cut Pro or Davinci Resolve to edit a video than FFMpeg. If someone became an expert in editing snippets into movies with ffmpeg from the command line and then told me that writing movies that require lots of editing is just bad writing and that it would be better if I wrote my movies so they required as little editing as possible I'd look at them funny.

Isn't it possible building up the system is a force multiplier in the same way that all the examples above the false restrictions prevent lots of progress?

Re: Why I teach vim

#180

Post by gen220 »

greggman3 wrote: post #177
gen220 wrote: post #171

Earlier quoted context omitted.

Sure! One example is vim-dispatch, which provides a convenient interface for executing arbitrary shell commands asynchronously. It works wonderfully with make, so you can run “make $file” in a couple strokes. I use this when writing markdown (to generate html with pandoc), editing test files, etc. Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, an…

Unfortunately I'm not understanding what makes vim special here > It works wonderfully with make, so you can run “make $file” in a couple strokes I can do this in any editor I've ever used > Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times. I can do this in most editors I used (VSC being an exception). I use re…

To clarify, I don't think these (or any) features are "vim-only".

I was intending to say that it's the meta-feature of vim that vim-users find so sticky, that you can trivially write your own features: composing arbitrary executables and modal editing.

I think most editors nowadays are taking a page out of vim's book, by exposing increasingly lower-level interfaces to extension authors and users.

In these ways, I think editors are converging with vim, over time. Vim (and emacs) has been this way forever.

You don't have to wait for the editor-making company to accept that your strange request is valid, you can just hack it on yourself.

Post reply on HN