Hacker News new | past | comments | ask | show | jobs | submit login

Awesome. Thanks for sharing. I've been using vim for 6 months, but I still feel like a n00b. Looking forward to checking this out.

I started my vim experience using Janus

But I didn't understand how anything worked or why any of the plugins were there.

That led me to starting from scratch (I forked my cofounder's dotfiles) and now I feel like I know my vim config waaaay better. If you've been using janus, I'd highly recommend giving the ground up strategy a shot.

https://github.com/sud0n1m/dotfiles




I wound up doing the same thing (not with Janus, but with a massive forked .vimrc).

One day I was SSH'd into a remote server and vim'd a directory by accident and I discovered Netrw. It wasn't the same as NERDTree, but it was good enough for me to get rid of that plugin. Eventually I just learned to enjoy the defaults with minor tweaks. Today my vimrc[1] is < 200 lines, mostly comments and navigation shortcuts.

[1]: https://github.com/mgirouard/Dots/blob/master/.vimrc


Nice, I have a bit more (eg Pyflakes highlighting, Pysmell completion) but I share the same trend: barebone vim (no gui, no mouse, no pathogen infection).

I was looking for the rightbelow this, found it in your vimrc. Found it weird you don't have wildmenu...


What is this netrw? http://www.vim.org/scripts/script.php?script_id=1075 seems to imply it's just for vim'ing remote files. Does it do more?



I used NERDTree for a long time until I saw a simple tutorial to netrw - now I love netrw and don't want to ever go back to NERDTree. It's simple and to the point and just works really well for me.


Hm.. maybe I need to take another look at netrw. Last time I played with it, the big thing that led me to prefer NERDTree was the difficulty in opening a file you navigated to in the pane to the right. It kept replacing the netrw pane.


As always, the answer is in the documentation (:help netrw):

    P


You can configure this with g:netrw_browse_split. Setting it to 4 will open the file in the previous window.

See :help netrw_browse_split for other options.


Keep at it, I've been using vim for 15 years and I also still feel like a noob.


I've been using it for about 17 years and I too am a noob. hjkl


I haven't made the jump from arrows to hjkl. My cofounder's keyboard is arrowless, but my HHKB lite still has the arrows. Maybe in another 5 years I'll make the switch.


It's vim, so no need for a hardware mod. Here's a trick that several vim writers recommend; add this to your .vimrc:

  " Disable arrow keys
  noremap <Up> <nop>
  noremap <Down> <nop>
  noremap <Left> <nop>
  noremap <Right> <nop>
It'll be super annoying for the first day or two, vexing for the rest of the week, then you'll just forget it's even there.


The hardware mod that made the most difference for me, typing-wise, was rearranging the tops of the keys. I'm not sure this is doable on modern laptop keyboards, but on desktop keyboards it's trivial, and I never realized just how much I looked at the keyboard until it would hurt, and the habit died quickly.


Using hjkl instead of the arrows is not a small difference. It's huge.

Staying on the home-row vs having to move your hand over and back constantly affects your speed and accuracy in a big way.

Here's an easy way to switch: never, ever use the arrow keys to move the cursor again. Done!


In addition, to deal with the issue that programs others than vi may require the use of arrow keys, I use Autohotkey on Windows to map Caps Lock + hjkl to the arrow keys! Thus, both in vi and outside(, in Word, say), I just use Caps Lock + hjkl to navigate. Thus, I never have to move my hand away from the "home" position to use the arrow keys.


I did that and it is actually incredibly easy to get used to (within a couple of hours). The bigger thing you have to get used to -- and which I suspect most will struggle with -- is not moving around when in insert mode.


hjkl may have started because the Joy was working on an ADM3A that had no home row, but the elegant and efficient consequence is that your hands fingers do not move from typing position.

you just have to map your tab key to escape to get the original layout back[1].

[1] http://en.wikipedia.org/wiki/File:KB_Terminal_ADM3A.svg


What do you use in insert mode?


Escape. Normal mode is for navigation. :)


I'd like to have your willpower!


If you want to learn the new way, disable the old way:

    inoremap <Left>  <NOP>
    inoremap <Right> <NOP>
    inoremap <Up>    <NOP>
    inoremap <Down>  <NOP>


Not using the arrow keys was a no-brainer back in the day of slow dial-up connections. Sending ^[OA over the wire instead of just h was a really big deal and when your connection dropped a byte you ended up with garbage in your files if you used the arrow keys. Having that sort of pain associated with their use has stuck with me ever since.


Yeah, I let hjkl discipline slide for a long time, too; it's damn hard to interrupt a reflexive reach for the easier to align cluster whose labels actually correspond to what you want to do. Here's the part that finally pushed me over: arrow keys can supplement/mirror/tweak anything you find overly awkward, slow, or hard to remember in the "native" form. And you can remap them straight (no prefixes/modifiers) or build something arbitrarily deep and be certain you won't interfere with any other bindings.

See? the arrow key scan become four more user keys, and they have easy to remember direction/orientation if you need it. Having trouble navigating, swapping, and resizing, your layout (and accidentally hosing text with ^w in the wrong mode? I did, but 20 minutes after seeing someone else use a similar setup, I was using my own variant more comfortably than any console window management bindings I'd ever tried before.

tl;dr; Remap the arrow keys from movement to anything you struggle with normally, and be amazed how you survived before your four newest "user" keys were liberated!

(Also, if anyone wants me to, I'd be happy to post my re-binding config lines as a template/sample.)


Does this really make that much difference? I kind of view the hjkl vs arrow keys like I view the standard debate about motion commands vs. the mouse.

Lots of people say they are faster using motion commands, and I know I use search motions 85% of the time. But if I want to go somewhere that's visible on the screen, the mouse is almost always quicker. And I've used vi and derivatives for 20+ years now (although obviously they initially didn't have mouse support :-)).

Similar for hjkl, especially if you use single cell motion mixed with whole page motion (Fn-arrow on a macbook), I just don't see hjkl + ^D^U being quicker. It seems more like something that might be useful every once in a while, but not terribly useful 100% or even 50% of the time.

EDIT: And the book says this:

"type the number of characters or lines you want the cursor to move, followed by h, j, k, or l. This technique cannot be used with the arrow keys: left, right, up, and down."

Which is not correct.


For me the mouse is never quicker. I think that over time your brain kind of memorizes the number of lines (rows) and characters (columns) available in your screen and it certainly gets to a point where you don't really think about the science behind motions and you end up just using motions defined through past experiences. I amaze myself (and my coworkers) when I apply a seemingly random number to a motion and I end up exactly where I wanted to be. Last time a coworker asked me if I'm a math freak and I did the calculations in my head when doing a complex motion in a second, and even though I answer that I am (jokingly), I know that it's actually just a combination of muscle memory and past memories.

In any case, even though I don't agree with the school that says that to learn vi/vim you should forgo arrow keys and non vim (cmd + s to save, command + left arrow to go the left of the line, etc) key combinations, I think that a major point of inflection while learning the editor is choosing a trick/combination/command that you want to learn because it will increase your productivity and keep forcing it, even if it means not using the arrow keys or other combinations you're not used to, until it becomes second nature. And then do the next one and so on.


For me it's not about wall clock quicker, but perceived quicker. I use a couple of different keyboards throughout the day, and they all have the arrows in slightly different places (more variation than letter keys...) which makes it similar to the mouse...

Namely, the amount of concentration required to hit an arrow or get the mouse to do what I want feels slower because I have to pause my thoughts, rather than just queue up a nerve message to my fingers to "then go over there and...". Stopping the train of thought to manipulate the mouse - which requires a lot more visual feedback and focus than just knowing that the cursor will get there - makes me overall slower because I'm context switching.


It makes some difference. It is worth doing for some comfort and speed. But it isn't true that you can't get by without it. It's just much clumsier than it needs to be.


I'm late responding but I've been trying the arrow keys more because of your comment and many others who use them. In the older *nix and depending on the shell, it seemed they didn't always work. On Ubuntu though, they work great! I might switch to using them, thanks for the tip.


One quick way to change your behaviour is by remapping the arrow keys to a NOOP. Took be about two days of solid coding afterwords to completely change my habits and have been reaping the awards ever since!


Don't do it! Once your fingers learn and start to prefer hjkl you'll waste a lot of time and effort in other programs trying to use them.

Really, more things just need vi-like interfaces :(


Name something you use that you think doesn't have a vi-like interface.


"Name something you use that you think doesn't have a vi-like interface."

- XCode

- Chrome

- Filthy XCode


For Chrome Vimium is fairly nice http://vimium.github.com/


To be fair, most vi-like interfaces suck or worse, they are clunky, incomplete or have odd bugs when interfacing with the rest of the program.


I would give all my money for a shell with a mode indicator be it cursor or modeline.


zsh can do that. eg. http://pthree.org/2009/03/28/add-vim-editing-mode-to-your-zs...

that was the first link on a ddg search. there were other articles. https://duckduckgo.com/?q=zsh+vi+mode+prompt


not sure if that says bad things about Vim or good...


I didn't use Janus, but I copied a really good, commented .vimrc from another Python and Ruby programmer. That was a mistake, but I didn't realise it at first because I thought "this does a lot of neat things that I need" but I had no idea what was really going on or how it was different from the default. So I did the same thing you did. Deleted it and started with blank dotfiles and no plugins.

I figured out that when you're in the learning stage with vim, you should always be editing your dotfiles because that's a big part of progressing up the learning curve.


I'm in the opposite boat: i stuck with Janus and actually dug in the source and played with it to understand exactly what was there. Janus is incredibly awesome and easy to extend, I'd highly recommend you gave it another chance and really read the docs and try to understand why it is what it is. Must have plugins are also https://github.com/tpope/vim-surround and https://github.com/tpope/vim-repeat


I'm also pretty new to vim (well at least using it seriously, for a quick config edit I've been using it for ages as it beats having to use nano).

I love reading other people's vimrc as I usually always find something new that I'm willing to try out. Mine is here in case someone wants to take a look: https://github.com/PatrickLerner/dotfiles/blob/master/vimrc


you always feel like a n00b with vim :)




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: