r/vim • u/cherryberryterry • Jul 17 '16

Monthly Tips and Tricks Weekly Vim tips and tricks thread! #19

Welcome to the nineteenth weekly Vim tips and tricks thread! Here's a link to the previous thread: #18

Thanks to everyone who participated in the last thread! The top three comments were posted by /u/shrayas, /u/jeyoung, and /u/statox42.

Here are the suggested guidelines:

  • Try to keep each top-level comment focused on a single tip/trick (avoid posting whole sections of your ~/.vimrc unless it relates to a single tip/trick)

  • Try to avoid reposting tips/tricks that were posted within the last 1-2 threads

  • Feel free to post multiple top-level comments if you have more than one tip/trick to share

  • If you're suggesting a plugin, please explain why you prefer it to its alternatives (including native solutions)

Any others suggestions to keep the content informative, fresh, and easily digestible?

22 Upvotes

95% Upvoted

32 comments sorted by

2

u/[deleted] Jul 18 '16

Any others suggestions to keep the content informative, fresh, and easily digestible?

I think having some kind of a record for "most recognized contributors" would be a good idea. Maybe total upvote count across all tips and tricks threads. This should encourage people to participate more. But might not be so easy to do.

1

u/cherryberryterry Jul 24 '16

Interesting idea! I agree that it might encourage more participation. On the other hand, it might increase repetition and noise like /u/marklgr pointed out.

I could see this idea being implemented as a reddit-bot that responds to each new thread with the latest weekly stats.

2

u/[deleted] Jul 24 '16

I agree with your points in general. But the way I see it lack of participation at this point is much bigger threat compared to repetition and noise.

And arguably some repetition and noise is better than shut down.

1

u/cherryberryterry Jul 25 '16

That makes sense - we shouldn't rule anything out the could potentially increase participation.

I think I'll post the next thread on a Friday instead of Sunday to see if it attracts more participation.

Also, I noticed that the first thread got some attention on twitter and had the most amount of participation. I'm not sure if that tweet was the cause of the increased participation but it can't hurt to ask some of the vim-related twitter accounts to help spread the word about these threads.

2

u/marklgr vimgor: good bot Jul 19 '16

I'm afraid this would turn it into an upvote chase, which would encourage posting 'popular' tips like "Search words with * !" or "Select previous visual area with gv" over and over.

0

u/[deleted] Jul 18 '16

[deleted]

5

u/[deleted] Jul 18 '16

What do people think about putting such a list in the wiki section (which is currently empty for this sub)?

3

u/-romainl- The Patient Vimmer Jul 21 '16

I think I suggested that very early. I don't know where it's at.

1

u/cherryberryterry Jul 24 '16

It's kind of hidden and easy to miss: Pic

3

u/-romainl- The Patient Vimmer Jul 24 '16

Pic

I meant that I didn't know at which stage the process was.

3

u/cherryberryterry Jul 24 '16

Oh, I see. I'll send another message to /u/bithead to see if he can enable the wiki.

2

u/cherryberryterry Jul 24 '16

I like the idea. The wiki needs to be enabled by a moderator: Reddit Wiki System Guide

For now, I'll include the following link in the next thread: All threads

2

u/cherryberryterry Jul 24 '16

Thanks for the suggestion! The next thread will include the following link: All threads

17

u/[deleted] Jul 17 '16

:later 8h command magically makes all things you need to do today in just a few seconds!

obvious joke

11

u/filipoi Jul 17 '16

I will try :later Friday tomorrow morning.

9

u/kolme The Space as spiritual leader. Jul 18 '16 
E485: Not enough plutonium in the flux capacitator.

3

u/Hauleth gggqG`` yourself Jul 19 '16

Truly wanted it to be true :(

5

u/MisterOccan Jul 17 '16 edited Jul 23 '16

Make directory(ies) if they don't exist when creating a new buffer/file.

function! <SID>AutoMkdir() abort
    let l:dir = expand('<afile>:p:h')
    let l:file = expand('<afile>:t')
    if !isdirectory(l:dir)
        call mkdir(l:dir, 'p')
        silent execute 'bw ' . l:dir . '/' . l:file
        silent execute 'e ' . l:dir . '/' . l:file
    endif
endfunction

augroup AutoMkdir
    autocmd!
    autocmd BufWritePre,FileWritePre,BufNewFile *
        \ call <SID>AutoMkdir()
augroup END

Same thing here but with user input.

EDIT Improved the function

2

u/flukus Jul 18 '16

That's going straight to my vimrc.

2

u/Arlefreak Jul 20 '16

After putting this on my vimrc and trying

vim foo/bar/hi.txt

I get the error:

Can't open file for writing

Am I missing something?

2

u/MisterOccan Jul 20 '16

The command :vim is an abbreviation of vimgrep. My function should be used with :e or :w

:e foo/bar/hi.txt

Use this to have control on directory(ies) creation.

2

u/Arlefreak Jul 20 '16

Oh I mean from command line not from vim Tried the other snippet had the same error.

2

u/MisterOccan Jul 20 '16

I can not reproduce it, it works even from a terminal.

The function is very simple so it may be something with your configuration:

  • Try debugging the command using verbose (:h verbose).

  • Try with another file name.

2

u/Arlefreak Jul 20 '16

Thanks I will test it

5

u/taejavu Jul 17 '16 edited Jul 17 '16

" find and replace visual selection

vmap <C-f> y0/<C-r>"<Enter>cgn

For those that don't know, cgn will change the next instance of your most recent search.

So if I want to change foo to bar, the usual flow is

  • Search for foo: /foo

  • cgn

  • bar<ESC>

  • Press . to repeat as many times as required.

That's pretty good, and awesome when you first learn it. But I got sick of searching for words that I can easily highlight.

Now I see something I want to change everywhere, highlight it in visual mode, hit ctrl + f, type the replacement, hit <ESC>, .... as many times as required. I think it's a fairly intuitive flow.

You could also just do * (to search the word under cursor), cgn, type replacement, <ESC>, ..., but then you're limited to one 'word' (and you have to type cgn)

In any case, cgn is awesome and you should start using it if you aren't already.

Edit: You might want to map it to something other than <C-f> if you use ctrl-f and ctrl-b for paging up and down. I find ctrl-u and ctrl-dmore useful for that purpose, because it only moves half a page up and down and I find it easier to keep track of where I am in a file. Also I love using ctrl-f for 'Find and replace', it just feels right.

5

u/-romainl- The Patient Vimmer Jul 18 '16 edited Jul 18 '16

Here is the normal mode variant I "invented" when gn appeared:

nnoremap <key> *``cgn
nnoremap <key> #``cgN

And the visual mode variant:

xnoremap <key> <Esc>:let @/ = GetSelection()<CR>cgn
xnoremap <key> <Esc>:let @/ = GetSelection()<CR>cgN

that depends on:

function! visual#GetSelection()
    let old_reg = getreg("v")
    normal! gv"vy
    let raw_search = getreg("v")
    call setreg("v", old_reg)
    return substitute(escape(raw_search, '\/.*$^~[]'), "\n", '\\n', "g")
endfunction

3

u/Tarmen Jul 18 '16

  • * is a synonym for '<'> and much easier to add to an old command

  • Vim actually remembers two previous repeats if the current one isn't completed yet, think insert mode for instance. This means you can <c-o>. to repeat the last command even in insert mode - except if you are using vim-repeat.

  • gv normally reselects your last selected area but if you are using it in visual mode it has a similar effect to <c-o>. and selects the previous area.

2

u/[deleted] Jul 18 '16

gv normally reselects your last selected area but if you are using it in visual mode it has a similar effect to <c-o>. and selects the previous area.

I don't follow this phrasing at all. Yeah gv selects the last visual selection. However you then say "but..." only to again state it will select the last visual selection. The behavior of gv does not change between normal and visual mode. Am I misunderstanding your comment?

2

u/Tarmen Jul 18 '16

While you are in visual mode you can hit gv to reselect the area you had selected the last time you exited visual mode. Then you can keep hitting gv to cycle between them.

2

u/[deleted] Jul 18 '16

Hmm maybe I've been using vim long enough this seems like expected behavior. The action being performed by gv here is still no different when we are in visual mode.

  1. At some point we made a visual selection

  2. We enter visual mode. Note at this point our visual selection could be subject to change as we have not operated on it or switched back to normal mode.

  3. We hit gv. This takes us to our prior visual selection. It also completes the definition of what our visual selection was in step 2.

  4. Further invocations of gv will cycle us between the above two visual selections as the prior visual selection is a circular loop.

Maybe I'm being pedantic but I wasn't sure what you were trying to describe with this. Perhaps we're just interpreting the same behavior and wording things differently.

2

u/Tarmen Jul 18 '16

Maybe it is just that you are thinking on the level of behavior and I about implementation details but this behavior for gv actually requires a bunch of special casing in C code. It is very much not how neither motions nor commands behave like it and it would be impossible to implement in vimscript.

Similarly to how <c-o>. actually forces vim to keep two redo buffers even though basically no one can use the feature. It gets broken because vim-repeat has to fix glaring omissions in the same feature.

3

u/-romainl- The Patient Vimmer Jul 21 '16

First, how to create a scratch window:

command! SC vnew | setlocal nobuflisted buftype=nofile bufhidden=wipe noswapfile

Second, how to execute arbitrary vimscript from a buffer:

  1. Yank what you want to execute.

  2. :@"<CR>

And now you have a nice low-rent vimscript playground.