Vim Croquet | Hacker News Reader

Vim Croquet

drbunsen.org

212 pointssaamm55 comments

Awesome! I'd love to see something like this as a standalone project. "Vim Critic" or "Vim Coach" - something to say "these are the inefficient things you personally do."

Probably some low-hanging fruit would be "any keystroke in Normal mode that's repeated." Eg, if I'm doing 'jjjj' to move down or even 'wwww' to hop from word to word, I could be searching or using a movement combo like '4j'.

Personally, the main reason I moved from vim to emacs is because I don't want to have to think about my editor, I want it to be pure muscle memory. I'm okay with hitting "jjjjk" to go 3 lines down rather than trying to guess that it's exactly 3 down and typing "3j". Emacs-style navigating/editing is great for this kind of error-tolerant navigation/editing. It leaves my brain mostly free to focus on whatever I'm actually coding at the time.

I think most experienced vim users will tell you that it is pure muscle memory for them. Also, vim supports jjjjk as well as 3j. Anyway, I just realized I am debating vim vs emacs so I'll stop here.

We all know the one true editor is the Chrome console anyway.

ewww

Nothing about vim forces you not to type jjjjk, or better yet use motions or whatever fits your brain. But keep up the good emacs-vs-vim-troll fight

I go with a hybrid approach: I hit the number row somewhere in the loose vicinity of the number of rows I want to move, and then hit "j" a couple times to get exactly there. If it's more than a single-digit number of rows away, I might do the first step more than once.

I think it's better to repeatedly hit j rather than count "ah, 5 lines" and type 5j. Even better, you're already looking at where you want to go, it may be faster to hit / and start typing from that point to jump there.

Or, and this is a wild one, grab the mouse and click the point where you want the cursor, rather than giving some sort of treasure map to Vim: "Starting at the typedef, take 5 steps right, then 10 steps down, and 2 more steps right"

A little tweak that got me in the habit of using things like 5j and 6dd: :set relativenumber.

It numbers your current line as 0, and counts up and down from there. It makes it very easy to see that you need to delete the next 5 lines, or move up 10 lines without doing any math.

As for your mouse comment, I don't think you can compare the speed with which an experienced vim user gets their cursor where they want it to the catastrophic cache miss of removing your hand from the comfort of the home row, grabbing the mouse, moving it where you want, clicking it, and moving your hand back to the keyboard. The mere thought makes me shudder :)

catastrophic cache miss

haha, great prose.

+1 for relative line numbers. I scripted up ctr+n so I can toggle between relative and absolute as needed, though, there are even plugins capable of intelligently switching when necessary (like http://www.vim.org/scripts/script.php?script_id=4212).

I prefer hybrid line numbering. This way, you can see the true number of the line you are on, while all the other lines on the screen are numbered relative to your position.

http://jeffkreeftmeijer.com/2013/vims-new-hybrid-line-number...

Now this is perfection. Get both relative line numbering and absolute line numbers.

However, I use the vim-powerline plugin which displays the current line number/total lines at the bottom which is enough for me.

As someone who watches a lot of people use Vim, I think many would be better off with a little judicious mouse use. Yes, you very busily slam keys, but it seems to take a pretty damn long time and a lot of keystrokes to actually accomplish the monumentally complex task of shifting the cursor 30 lines down and 10 characters over.

My trackball is all of 4 inches from my right hand, and I always know where it is because it doesn't move around. Now, you can try and overplay the difficulty of grabbing the pointer ("I have to instruct my arm muscles to tense and pivot at both the elbow and shoulder while causing my fingers to curl into the appropriate shape" and so on) but I'd wager I could get the cursor to a given semi-distant point on a screen of code faster than even the most frantic of vim key-pounders.

Yes, yes, yes. As someone who used to buy into keyboard fascism, I wholeheartedly agree with this. I consider myself proficient with Vim (and Emacs) in terms of keyboard controls, and know all of the fancy Vim motions and text objects.

However, even when editor keyboard commands become "muscle memory", there's still a little part of your brain that has to make a decision regarding how you're going to navigate/select/change/delete from point A to point B. With the mouse, you don't have to think up an algorithm for editing. You just think about the code at hand. I've found that the fraction-of-a-second decision making regarding _how_ to edit can be enough to interrupt my train of thought. Reading this article ( http://www.asktog.com/TOI/toi06KeyboardVMouse1.html ), while it may be quite old, helped me realize this fact.

That being said, I still think Vim is a great editor, and I don't mean to make any blanket statements about it's effectiveness. I just also believe that the obsession with "efficiency" is totally blown up with regards to editing text. Shouldn't we strive for efficiency in translating algorithmic thought to programming language? I think the keyboard crowd (myself included) tends to get caught up in the little details.

:set mouse=a enables mouse pointer in vim

The keyboard heatmap code is nifty enough to justify this being on the front page of HN all by itself, which is not to say the rest is without value -- quite the converse; I hadn't thought of doing this sort of usage analysis with Emacs, but I think that's going to be my next weekend project once I'm done updating weatherline-mode.

Judging by the heatmap, it appears the author isn't familiar with Vim's c verb.

It works just like d, except it puts you in insert mode after you've completed your command.

For example, to replace the text within a set of quotation marks with You don't like Vim?, move your cursor on or within those quotation marks and use:

    ci"You don't like Vim?<esc>

To replace the text up to (but not including) the next exclamation point with I would never drink orange juice, use:

    ct!I would never drink orange juice<esc>

EDIT: Gah. He explicitly mentioned his use of cib. I'll leave this here in case it helps anyone.

Judging from his discussion of cib in the Data Acquisition section, it seems like he's familiar with it.

Perhaps familiar, but not ingrained in his muscle memory to used instead of d<motion>i.

To be fair, I'll often do that as well, but just looking at the keys misses that there's a pause between the d<motion> and the i. I don't like sitting in insert mode, so if I don't know what I'm going to replace a thing with, I'd rather delete it, then insert something else after I've figured it out.

Even if not related to it and my get some downvoted for saying this. Something that strike me in this post is how cooler haskell code looks vs python.

The nice thing with Haskell is that it can be extremely compact. The problem with Haskell is that it can be extremely compact.

map (format "The %s thing with Haskell is that it can be extremely compact") ["nice thing", "problem"]

(disclaimer: that probably isn't actual Haskell syntax.)

    mapM_ (printf "The %s thing with Haskell is that it can be extremely compact\n")
          ["nice thing", "problem"]

This works. :)

Alternatively, you could do this:

    forM_ ["nice thing", "problem"] $
          printf "The %s thing with Haskell is that it can be extremely compact\n"

map (("The "++).(++" with Haskell is that it can be extremely compact")) ["nice thing", "problem"]

For values of "cool" meaning "undecipherable", sure.

This is a common misconception. Haskell is extremely readable. You just have to learn it.

Python reads like pseudo-code where as Haskell reads like math. Both are readable, they are just different.

I suspect it's easier to teach someone Haskell if they have never done imperative programming before because they have a lot less hang ups.

I think this is a fairly insightful analysis. Haskell seems to be semantically very dense - each symbol or function packs a lot of meaning.

Reading Haskell for me is like when I had to do math proofs in Real Analysis or Abstract Algebra - it takes a fair amount of time to get into the mode where I can understand what is written very concisely in front of me.

To me it seems that Haskell suffers from some of the same problem that mathematics does - it is very concise notation for someone already familiar with the concepts, and a lot faster to write if you are familiar, but reading requires unpacking all the meaning of the notation, so ultimately is far more time consuming unless you are already familiar with the concepts that are in the code.

The "joke" was that Haskell looks very different from most popular programming languages, and that folks who think it "looks cooler than Python" are likely reacting to its indecipherability combined with the fact that it's clearly doing something interesting.

At least Python programmers have a sense of humor.

Using a language that eschews state to try and process the state in a modal editor tickles me.

To elaborate on the other reply, Haskell actually takes a very in-depth and principled approach to managing state. State is necessary for many applications, so rather than eschew it entirely, the idea is to isolate it and make it as explicit as possible. Frequently in complex stateful applications this is done by use of the State monad, with lenses to handle mutation of that state. There's a lot of theory behind it, but in practice it ends up being pretty similar in difficulty level to managing state in more popular languages, just a hell of a lot safer.

I know others have said it, but I would like to echo the "please don't say that Haskell eschews state" message :)

It doesn't. You can't run a program made of only pure functions. What it does it manage it.

Parsing and lexing in Haskell is one of its shining glories.

Looking at the heat map, what does surprise me is how he never uses Escape or ^[. How does he managed to move out of Insert mode? My [ key is starting to wear out due to such heavy use..

> Looking at the heat map, what does surprise me is how he never uses Escape or ^[. How does he managed to move out of Insert mode?

His 3rd most used command is jj. This is popular among some vim users to be remapped as Esc in insert mode (:inoremap jj <Esc>).

I do not personally use this but when writing this comment, I quickly tested it out and it actually feels quite comfortable.

I re-map my caps lock as Escape. It works suprisingly well even outside of Vim.

I don't use vim, but from the parsing example he gives in the post, I'm guessing he uses C-c:

    `Mihere's some text^Cyyp$bimore ^C0~A.^C:w^M:q

[…]

> The lexer correctly determined that I started in normal mode by navigating to a specific buffer using the `M mark, then typed here's some text in insert mode, then[…]

Wow. I never knew about that one.

I use ctrl+c. It's easy to hit than esc, and it's built in, so it always works, even on servers i haven't set my config for, etc.

I don't know about him but I have 'kj' mapped to <Esc>. I highly recommend it. (or any variation around it)

He may have it set up the way I do: if I tap Ctrl rather than holding it, it sends Escape. If that's the case, his heatmap might be lumping Escape and Ctrl together.

Remapping?

This is very cool. Can anyone point me in the general direction of how to implement this on my machine? I understand logging keystrokes in Vim, but I'm not sure how to use the source code given for the lexer, or that given for the Makefile.

ggvG$"zy can be replaced with ggVG"zy

Visual line mode is often very convenient.

Also, kana's text-object-entire plugin may come in handy here (many of her text-object plugins are very useful).

Better still, I'll recommend @kana's vim-textobj-entire[1]. This adds 'e' as an 'everything' text object, with 'ae' (around everything) and 'ie' (inside everything) bindings by default. Thus 'vie' would select everything in the buffer in visual mode. Likewise for 'Vie' (Visual line select) or 'cie' (change everything).

[1] https://github.com/kana/vim-textobj-entire

    :%yz

Good call! But you'll need a space:

    :%y z

Also you don't need any visual mode if you don't need visual feedback. Yanking everything:

    gg"zyG

If I can recall the file name, :r <file name> might be a better choice than gg...y

This guy should definitely start using caps lock as control.

If you read more closely, he mentions that he uses a Kinesis Advantage where his control key is quite convenient. The heatmap is just plotted on a standard keyboard.

http://www.drbunsen.org/an-affray-with-rsi/

his end key is escape. on his keyboard i think it translates to being on a thumb

Bay area folks, please join Vim meetups http://www.meetup.com/vim-ed/

This needs to be a standalone tool. Is it on github somewhere? Or do I have to copy/paste from the article?

Awesome stuff!!!!

Reply on news.ycombinator.com