Willkommen, bienvenue, welcome, welkomEdit

Welcome to the Vim Tips wiki! We hope you can help improve the articles by fixing typos, adding comments (at the bottom of each tip page), rewriting tips, joining in discussions, or making other improvements.

Be sure to visit the community portal for information about our site, with links to how to pages.

Keep an eye on recent changes to check progress.

Our policy guidelines may be useful. We'd like you to join the very low-volume mailing list.


Hi Chrisbra, welcome to the Vim Tips wiki! Thanks for your edit to the File:Undo tree.vim.png page. It's always great to see new contributors. This is an automated message; somebody may drop a message for you here in the next day or two with any comments or suggestions, but until then keep up the good work, and don't be afraid to be bold!

Please leave a message on my talk page if I can help with anything. -- JohnBeckett (Talk) 20:51, May 11, 2010

Rollback Edit

Thanks for reverting those recent vandalisms. I just allocated you the rollback right to make that a little easier. After checking the diff and deciding the changes were bad, you can click "rollback" (an extra link next to the most recent edit). That removes all consecutive edits by the same IP or user with a standard edit summary. On the other hand, the fact that you see the rollback link can be a little irritating (and somewhat easy to hit accidentally), so if you don't want it please reply here). JohnBeckett 03:53, November 1, 2011 (UTC)

Thanks, let me try how I get around with that Chrisbra 06:39, November 1, 2011 (UTC)

Batch rollbackEdit

WOW. Good use of your new rights for this nonsense:


Did you get through all 103 of the edits on the list?

If so, did you find some way to do a "batch rollback", or did you need to do each page manually?

--Fritzophrenic 17:54, November 8, 2011 (UTC)

I noticed this nonsense, when he made changes to one of the pages, I am watching, so using the rollback permission I got recently, I manually rolled back each change as it happened (well almost...). Still, several clicks were neccessary. Chrisbra 20:03, November 8, 2011 (UTC)

Merging tips Edit

Thanks for merging some old tips (I notice you did that recently and in the past). I think that's one of the most valuable things to do here as it removes obsolete gunk, and reduces the number of tips that need fixing. I'm leaving a note with a suggestion for next time.

It's best to avoid any possible upset to someone who might have created a tip. So I no longer refer to deleting old tips as not useful (with a couple of exceptions for out-of-place material where we don't have an alternative tip with replacement text). Another issue is that we should credit material that is added to a tip (that's desirable, and it's part of the copyright as it is supposed to be possible to work out who-contributed-what from page histories).

Suppose tip 1100 is called "Some old tip" and better material is at tip 1200 which is "Improved tip", but 1100 has some useful info. My procedure:

  • Edit 1200 and paste in an exact copy of the 1100 page (including its tip template and all comments) under a new heading like the following, with an edit summary like the following:
    • Heading: ==Copy of 1100 [[Some old tip]]==
    • Edit summary: Merge from 1100 [[Some old tip]]
  • Edit 1200 again (perhaps immediately after saving above, or in a few weeks time). Do the actual merging (delete the "Copy of" heading, and the tip template for 1100, and old comments and stuff that's not wanted). This is just a standard edit, with an edit summary like "merge".
  • Edit 1100 and replace it with a redirect:
    • Content: #REDIRECT [[Improved tip]]==
    • Edit summary: Merge to 1200 [[Improved tip]]

If 1100 is actually junk, you might do all the steps above, but end up deleting everything that was copied from 1100. The edit summary would still be as above ("merged") on the basis that all useful material for current Vim is now at 1200 (but there was nothing useful).

The details of the above are not vital, and we worked for years without doing these steps, so any glitches or forgotten steps can be ignored. The rationale is that the above makes it easier to work out what happened at some time in the future. For example, a comment from 1100 might end up as part of 1200. Looking at the history of 1200, someone can determine when the material was added, and there will be a link in the history identifying where the material came from. If wanted, the person could check the history of 1100 and see how that material was originally added to the wiki.

There is one more detail, but I think it's best to leave that to me (that is, ignore the following). Anyone is welcome to do it, but it's routine trivia that is easy for me to do, and I have a script which I run every few months; it tells me if there is any navigation that needs fixing. The detail is that someone has to check "What links here" (in sidebar toolbox) when looking at tip 1100. One thing that will link to the old tip is VimTip1100. That page (for a real example) would be a redirect, and it needs to be changed:

  • Old content: #REDIRECT [[Some old tip]]
  • New content: #REDIRECT [[Improved tip]]
  • Edit summary: Fix redirect for merged tip.

There are sometimes other pages linking to the old tip. If it is in a normal tip, the link should be updated to the new destination. If it is on a user page or a "New tips" page, it should be left unchanged.

Sorry to drop all this here, but I wanted to document what I think is "best practice" somewhere. JohnBeckett (talk) 10:42, August 29, 2012 (UTC)

Try your code firstEdit


You added an example to the Search and replace tip, but I think you did not test your code - that isn't works on my system (tried out on Debian Sid & Win Xp, terminal & GUI, v7.3.547-7) The :substitute does not executes the second part of the command with the n flag.

--BimbaLaszlo (talk) 06:12, May 4, 2013 (UTC)

It works well. The problem is that you do not have a version of Vim that satisfies "With a recent enough Vim". I think it was Chrisbra who created the patch that Bram applied to Vim a few months ago which fixed what you are referring to. I would like to find the patch number because I'm planning to fix Copy search matches to use the much better technique that current Vim offers, and would like to be a bit more precise about which version of Vim is required. JohnBeckett (talk) 06:48, May 4, 2013 (UTC)
You need at least patch 7.3.627, which makes those things work. I initially created that patch, so that my Colorizer plugin works without creating many undo-states. (commit referencing patch 7.3.627). Chrisbra (talk) 11:01, May 4, 2013 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.