Vim Tips Wiki

This is an archive – please don't edit.

Tip 80[]

Thanks for your valuable contribution to Tip 80: Restore cursor to file position in previous editing session. I have removed both of our names from the "comments" section of that article per the comment guidelines. Although the "imported tip" notice says to avoid the article's talk page, at some point in the cleanup the talk page should start being used and perhaps now is the time. Comments directed at individual editors should be placed on their talk pages. (If you decide to start the talk page for that article, please send me a note on my talk page.) Thanks. -- Danorton (talk) 13:04, 28 July 2008 (UTC)

Of course you're absolutely correct about how wikis should run in general. I don't know if you've been watching progress here, but those of us who saw the import of the tips from, and then the immense amount of work to get the tips into some sort of shape, have formed the opinion that we still need to be different here.
To get an idea of what's happened, you could browse the list of 578 tips that we renamed. Apart from silly names, every title with a dodgy character like '[' ended up here with 'OPENBRACKET' in the name. In the tips themselves, every ampersand was '__AT__' (to obfuscate the many email addresses from the more innocent days when the tips were started on There are a lot of ampersands in Vim tips! Then there are the tips -- many of which are entirely broken or misguided or obsolete.
Anyway, we argued for a month about the talk pages, but the people who stayed on to do the work all agreed to avoid the talk pages for tips. We've recently had our first and only example where using such a talk page is actually helpful. I'll ramble on about this some more if you want to hear my reasoning, but in brief, it's simply that we want to work on one page rather than two, and we don't have any comments that are worth keeping, other than the ones we want visible on the tip page. I will definitely be revisiting VimTip80 and removing the comment I made.
It's great to have a contributor with wiki experience and who reads our guidelines! Thanks also for politely calling my contribution on tip 80 "valuable" -- perhaps an exaggeration, although I hope to return with something helpful. --JohnBeckett 00:06, 29 July 2008 (UTC)


Thanks for moving the remaining info in this tip to VimTip1182. You've saved me quite a bit of searching through the tips, as I would have been to annoyed by this tip to leave it alone ;-) -- BenArmston 13:20, 11 August 2008 (UTC)

Thank you -- glad to help clear out one more unwanted tip! It's easier to find stuff when you have a local copy of the wikitext of each tip. One day I might put a zip of that somewhere. --JohnBeckett 22:15, 11 August 2008 (UTC)

Adding links to removed tips[]

I recently came across a link to Tip 329 <>. This tip has been removed from the Wiki. But there is no information why it was removed or what can be done instead. I guess that's also the case for other removed tips. If tips are removed shouldn't they get links to tips that supersede them or at least some information on why they are removed?

I found which seems similar to the removed tip. Can I add a link to the removed tip?

Dennis Benzinger 19:42, 4 September 2008 (UTC)

Thanks for reporting this Dennis. Exactly one year ago (on 4 Sep 2007), VimTip329 was merged to VimTip47. In those early days, I hadn't devised a system for handling merges, and there are another 75 removed tips that have no explanation (I've got a local copy of the files and, now you've pointed it out, I can easily grep them). Looking at it positively, there are 81 more recently removed tips that do have an explanation, for example VimTip5. These days (since about February, I think), all removed tips have some sort of brief explanation added.
I have just updated 329 to show that it was merged to 47. While I'd like to process the other 75, it's probably too much work. However, I might try to find any more broken links. For example, in VimTip1077 there is a link to 329 that should be changed to 47.
Perhaps VimTip47 and VimTip1539 ("Exchanging adjacent words") should have a "See also" to each other. Hmmm. In 1539, you can click the "Created" link at the top and see the discussion that occurred when the tip was accepted. In that discussion, I also said there should be a "See also"! --JohnBeckett 01:58, 5 September 2008 (UTC)
Update: I had some tools that did the job: There were 28 links in 19 tips where the link was to a removed VimTipNumber page. I have fixed these. If you want to see them, consult 'Recent changes' and click 'Show bots'. --JohnBeckett 07:59, 5 September 2008 (UTC)

I noticed today that the stats page Vim Tips Wiki:Statistics/VimTip, created and maintained by User:Vimbot, has several links to removed tips. I just thought you might want to know. — Tonymec 00:50, 27 February 2009 (UTC)

Thanks. I'll look at it at some later stage. The statistics (and Vimbot) were set up by bastl who did the import of tips from Bastl got busy elsewhere and I don't expect to see him in the foreseeable future. --JohnBeckett 03:37, 27 February 2009 (UTC)

Corrections welcome on tip 225 and title change?[]

It's very pleasant to be welcomed that way, I don't know if it's the right way to answer you (I'm new on this kind of wiki). As I'm not a native english speaker, I'm grateful to any corrections.

I also think it would be a good thing to change the title of tip 225 from:

Vim can interact with xdvi


Vim can interact with xdvi or kdvi

Regards, Corentin Corentin.barbu 09:10, 5 December 2008 (UTC)

I will reply on your talk page. --JohnBeckett 09:52, 5 December 2008 (UTC)

Bug in help docs with index.txt[]

I just discovered while editing Best_Vim_Tips#Easter_Eggs that any help links to index.txt will fail, because help.txt is converted to index.html in order to have it show up if just the directory is entered instead of the full path. I thought I'd let you know, since I'm not sure whom to contact about about it. --Fritzophrenic 14:55, 5 December 2008 (UTC)

Thanks -- this problem is in several tips. When Dan Sharp put the Vim 7.2 files on vimdoc, he had to run a program that I supplied which munges the help tags file to construct a tagsidx file which maps help keywords to the correct html file and anchor. It looks like Dan has used an old version of that program because the version from 2007-07-16 has a workaround for the problem you identify.
I will contact Dan and try to sort this out. Ironically, the help CGI script files for Vim 7.0 are still on vimplugin, and they include the correct tagsidx file. There are various workarounds I could do to patch the wiki to give a correct link (the correct page is vimindex.html, not index.html), but I don't think it's worthwhile. I imagine I'll be able to sort out with Dan how to fix the issue in a few days. --JohnBeckett 23:59, 5 December 2008 (UTC)
I sent the correct file to Dan and he has installed it on vimdoc, so all the help links should work now. --JohnBeckett 22:27, 8 December 2008 (UTC)

Remove or keep imported info in tip headers?[]

Hi John! Is there a policy on keeping or removing imported info in tip headers? For example the author, version, complexity and created fields. Dennis Benzinger 17:27, 16 February 2009 (UTC)

Hi Dennis, Please keep the tip headers for now. If we ever decide to get rid of them, we can modify the tip template so that it displays nothing (or omits fields we don't want). Alternatively, I can use my bot to remove the header from each tip.
You might have noticed that I sometimes change the info in the imported tip header. Frankly, I would suggest others don't bother, but you're welcome to do what I do, if you like. If the created date is 2005 or before, I sometimes delete the month/day (one day I'll write a script to do that to all tips). I might adjust the complexity (but it's hardly worthwhile). I often change "version=5.x" to 6.0 or 7.0. I occasionally delete the author (displays nothing, see example) after checking that the author's original tip (from history) has been more or less replaced by subsequent edits/merges. If the tip introduced some clever angle, I'm inclined to keep the author to credit their work, but eventually we might just remove them all? See my further thoughts in another discussion. --JohnBeckett 22:23, 16 February 2009 (UTC)
I'd keep the author names but rename the field to "Original Author" so that it's clear that this is not the only or the last author. --Dennis Benzinger 11:18, 17 February 2009 (UTC)
I'll second the idea of changing that field's name to "original author" or similar. But, I think we should still omit the name when the original content has been entirely replaced. --Fritzophrenic 15:29, 17 February 2009 (UTC)
I'd even keep the original author in this case. I view this field as the first entry in the revision history of the tip. I think attribution is an important incentive for wiki authors. You don't delete the authors from the revision history if their edits get overwritten. --Dennis Benzinger 16:09, 17 February 2009 (UTC)

I have done an edit to show how tip 6 would look if "original author" were used. On my system, if the browser window is 1075 pixels wide the header line of the previous tip 6 did not wrap. Now that it says "original author" it definitely wraps. Normally I would hate the wrapping of the header, but it might be regarded as a bonus because it helps to push the tip down, below the ad.

Taking an idea from what Dennis said, I could have my bot do a dummy edit of every tip with edit summary "original author of tip was NAME". Then we could just remove the author and feel we weren't unduly ignoring them. It is a bit unfair how the authors of some tips are credited, despite the fact that the original tip was defective, and it's been fixed by wiki editors.

What about new tips? I would be happy to omit the author from them because the edit history clearly shows the story. It could be argued that showing the new author is good to encourage people to post new tips, but I take the opposite view. We have over 1250 tips, and really don't need any more (particularly we don't need some of the very simple or duplicate new tips we've had in the last year), so I don't mind crediting authors only in the edit history. --JohnBeckett 05:40, 19 February 2009 (UTC)

I don't think the edit history will be enough, because quite often the submitter of a tip is a new or not-logged-in user and only their IP address shows in the edit history. If we really want to avoid wrapping in most cases, we could use "Creator" or "Submitter" or something instead of "Original Author". Although, I certainly wouldn't argue too much against removing the author altogether. This is a wiki, after all. I mostly like it for the tradition of it, but it seems to cause more trouble than it's worth. --Fritzophrenic 14:55, 19 February 2009 (UTC)
It's not common that a new tip comes from an anon user (IP address), and they put their name in the tip. When that occurs, I could make it part of the "tip acceptance" procedure to put the author's name in the edit history. --JohnBeckett 20:27, 19 February 2009 (UTC)
Ah, yes...somehow it didn't occur to me (even though we're discussing it) that we always need to make at least 1 edit to a new tip, to add the tip template. If we just make the summary of this edit include " tip submitted by xxxx" for those who give a name, then I really like this solution. Why don't we pose it to the community via the wiki mailing list and/or vim_use to make sure there isn't too much outcry before implementing it? --Fritzophrenic 22:27, 19 February 2009 (UTC)
I don't mind if the header wraps. For new tips I'd omit the author because it's in the history. And because I'd prefer that old and new tips look the same I like the idea of an automated edit which records the original author in the edit history and removes the field from the header. --Dennis Benzinger 15:56, 19 February 2009 (UTC)
We sometimes get an anon user (has not logged on) who creates a tip and puts a name at the bottom of the tip. I record that name (and remove it from the tip). If the tip is accepted, I put the name into the TipNew template. So Fritzophrenic's point is that we know the author's name, but it's not in the edit history. However, it sounds like everyone here likes the suggestion that in those cases we put the author's name in an edit summary so it is publicly recorded.
I'm not in a big hurry to do this (I'm a bit caught up, and a fair bit of scripting would be involved). However, I'll take Fritzophrenic's suggestion and post a message on our vim-l mailing list, and on vim_use so people can offer their thoughts. I'll probably do that tomorrow. --JohnBeckett 06:57, 20 February 2009 (UTC)

Question template[]

John, I just tried using {{subst:question}} on a recent talk page submission, but it didn't work. I don't think I did anything differently than I have in the you know what is going on?

At first I thought it might be a problem with case sensitivity, but I double-checked and the error message, my text, and the instructions in Template:Question all match.

--Fritzophrenic 20:48, 24 March 2009 (UTC)

The template gives an error unless invoked with an unused argument named "unusedarg". So {{subst:question}} gives an error, but {{subst:question|unusedarg=x}} gives the desired result — Tonymec 22:50, 24 March 2009 (UTC)
Thanks, Tony. It looks like it took a few tries to get right. Any idea what the cause of this is? --Fritzophrenic 01:00, 25 March 2009 (UTC)
This silly template has caused nothing but grief! I sweated myself silly six months ago, determined to clean up its former problems, and to work out how to force "subst" to be used (with some ultra-complex examples from Wikipedia as the starting point). It's probably the new parser that has broken the template's behaviour, although fiddling with Special:ParserDiffTest did not reveal anything. Interestingly, I have recently had a real-life conversation with one of the principal MediaWiki developers (the author of the new parser), and another developer employed by MediaWiki. However, I don't think I'll work up enough enthusiasm to whinge to them...
The 'unusedarg' is supposed to be a truly not used argument to the template (see its source, if you don't mind going blind; {{{unusedarg|}}} is some clever trick). When I run out of things to do today, I'll have a closer look at what's going on. Thanks Tony! JohnBeckett 01:42, 25 March 2009 (UTC)
You're right that the source is not of the most readable — it didn't make me blind but it did make me squint; and since in fact I don't know how to program templates, I had not only to look at the source, but also to dig up the appropriate references in en:wiki help and Mediawiki help, as well as try various examples in User:Tonymec/Sandbox, until I got something workable. :-). Happily the Wiki help is quite extensive (though not as much as the Vim help of course ;-) ) if you know where to look for it. — Tonymec 08:08, 25 March 2009 (UTC)

Where to report vandalism[]

I've taken the liberty of blocking the IP address of a recent vandal. Should I also report the IP to someone on Wikia staff? Where would I do this? --Fritzophrenic 22:22, 19 April 2009 (UTC)

Normally I would just do what you've done and forget it, but in this case I think it should be reported for someone to monitor. I don't think the spam blacklist is the right place, and the only thing I can find at is some useless advice on assuming good faith. I have frequently seen advice to directly contact Wikia (in fact I was recently told to do that after emailing the Wikia list to report a bug), so let's do that. I would do it right now but I see a slight hint that you might want to do it. Please let me know that you've done it, and what happened (email me if sensitive). Rather than providing just a link, here is how we can remember to find it: Click "Special pages" in the sidebar, then find and click "Contact Wikia". It offers an email, but I gather that they intend us to complete the web form. I would give a quick but explicit summary: we are reporting a case of vandalism because of its content (with user contributions link). In more extreme cases, I would also email User:Uberfuzzy (Wikia staff). Remember also that Special pages holds "Protect site" which can be used to temporarily block all edits if warranted. JohnBeckett 00:18, 20 April 2009 (UTC)
Thanks, John. I've used the form to contact wikia staff, and am now waiting on a response. I'll let you know when I get one. --Fritzophrenic 13:47, 20 April 2009 (UTC)

As a plain user (as opposed to an admin or bot) I don't have the scope to detect systematic vandalism. When I notice that one specific page has been vandalized, I revert the change by means of the (undo) link on the history diff page, and I trust admins and/or bots to notice any systematic vandalism and take appropriate measures. Just logging here what I do, no reply needed unless something else should be done, instead or in addition. — Tonymec 08:05, 19 May 2009 (UTC)

New tip[]

Hi John, I just created a new tip, Going to the nth-from-last window. Rather obvious once you're shown it but it took me some time to get the right answer.
I notice that the New tips page apparently doesn't list anything for May 2009, or even for April. Should I create a new section? Or are you running a monthly bot job to do it? — Tonymec 01:45, 4 May 2009 (UTC)

Thanks Tony, after your reminder I have just fixed April. I'll do May a little later (when doing April, I found my script thought every page edited in April had been created in April ... probably related to a recent MediaWiki upgrade; I'll investigate later).
If you feel like commenting on some of the new tips, that would be great. However, please be realistic: given the low probability of any weak tips being fixed soon, we need honest assessments of whether each tip is worthwhile (bearing in mind that each one we keep is an overhead for readers and editors). JohnBeckett 04:44, 4 May 2009 (UTC)

Hey, yourself[]

It's hilarious to be called a "experienced editor," but I'm too proud to beg for a fitting complement, so we'll let that rest. I appreciate that you seem to have a good sense of how firm to be with folks who clearly don't read FAQs, and yet you aren't just adopting wikipedia policies that don't fit. It's so nice to see plain, good judgement at the helm.

I'm trying to get a sense of direction at the moment, so please don't mind me pushing at the junk a bit. I'm not sure I know what belongs here. Some stuff seems tutorial, some theoretical, some like a cookbook recipe, others like a design pattern. And I'm certainly unclear on the tips' relation to the help docs. Are there particular tips which are good examples of the common forms?

Well, I'd say any of our featured tips should be good examples of our common practices. But you can find them on almost any tip without a {{review}} template. You're right that our tips seem to fall into several broad purposes; I think you've captured them well. We don't tend to like the "cookbook" ones unless there's a lot of explanation to go along with them, the tutorial and theoretical are nice and we have a lot of those, and we've been getting more of the design pattern ones relatively recently. I'd almost call those a sort of "advanced tutorial".
Personally, I disagree with John slightly on his stance on "junk" pages. My philosophy is that we have so much that needs a lot of work that it will take a really long time to figure out what to do with all of it, so we may as well fix it up little by little until someone takes the initiative to merge it or handle it in a better way. In general, when in doubt, leave it, but try to consolodate as much as possible. --Fritzophrenic 16:47, 18 May 2009 (UTC)

I'll be sure to use the comments instead of talk pages where appropriate, but I've noticed you use todos in a unique way. Are there any other tricks you're using to manage all this?

We do have several templates that we use to make our job eaisier. {{delete}}, {{dodgy}}, {{deprecated}}, {{duplicate}}, {{help}}, and {{script}} are probably the most used. And there's our new tip procedure, where John scripts the addition of any new tips into a discussion page every month, so we can merge or get rid of some of the less useful pages before they get very far. --Fritzophrenic 16:47, 18 May 2009 (UTC)

I'll try to keep with the existing style, tt vs code, etc. I would argue for code, but without kbd, var and samp, there's no real difference to me. Are there plans to add syntax highlighting to the wiki?

I hope these questions aren't too obvious. It's good to see this wiki has life behind it, and thanks for the less than automated post. --Josephholsten 14:11, 18 May 2009 (UTC)

I put what I think is digestible in the guidelines. It's too hard to read more detail, so I don't think I'll bother documenting much more. So long as it doesn't irritate you, I think it's best if I or Fritzophrenic comment when we think you should know some background about the very informal and vague policies here.
Wikia provide all the hardware and software on an "as is" basis. They continually update stuff, but they are aiming for fancruft and game people – I'm dreading the arrival of a "visual editor" which they have mentioned. So, no, I do not expect to get syntax highlighting (I believe it is available on request, but I don't think anyone has written the rules that would be required for Vim ... I suppose that is achievable).
Re Fritzophrenic's above comment about "junk" pages: I think he's saying that I might be a bit too aggressive in my quest to delete things. It's true that I think the dead wood is preventing us from getting a decent wiki, but I totally agree that all useful information should be retained somewhere, but I do not think that all information should be retained. I have found it quite useful to sometimes copy the wikitext from one tip to another, then delete the first and later edit the second (see VimTip269, VimTip356, VimTip1199 for examples).
Please feel free to ask or discuss stuff at any time. JohnBeckett 00:04, 19 May 2009 (UTC)


There was once an unanswered question on the Vim on Freenode. I've moved that question (and one answer) to PuTTY numeric keypad mappings.

I want to leave a link on Vim on Freenode pointing to that answer. Feel free to delete the rest of the now-irrelevant discussion you and I had on the Vim on Freenode‎ page. --DavidCary 03:13, 2 June 2009 (UTC)

Replied here. JohnBeckett 11:17, 2 June 2009 (UTC)

Syntax highlighting for Vimscript[]

Test page: User:JohnBeckett/Syntax highlighting

The GeSHi Generic Syntax Highlighter extension is apparently available on Wikia by request. Apparently the current version now supports Vimscript. However, it looks like Wikia do not yet have the current version.

Wikipedia do not, because I tried some Vimscript in the Wikipedia sandbox and got an error message that they have GeSHi- which does not support Vimscript.

My guess is that we will have syntax highlighting in some months. Of course we'll have to see how it works in practice. Following is an example of the wikitext. Note that the <pre> and </pre> lines are replaced by other magic, so it's quite reasonable.

<source lang="vimscript">
function QuickExample()
  let myvar = 'Hello World'
  return myvar

I just emailed Wikia asking for information and will post here with the results. JohnBeckett 01:14, 10 June 2009 (UTC)


The extension is now enabled. However, it is not the latest release, and if you try the above sample (remove the pre tags and click 'Show preview') you will see that it gives an error that 'vimscript' is not supported, and it lists what languages are supported.

When WMF releases a new stable version of MediaWiki, even a minor rev like 1.15.0 → 1.15.1, Wikia upgrades MediaWikia and all the extensions. When the above bug report ("looks like" link) is resolved, Wikia may attempt to upgrade GeSHi. A bit frustrating, but we have plenty of other issues to resolve, and it's understandable that Wikia need to take their time before upgrading their complex systems. JohnBeckett 01:13, 11 June 2009 (UTC)

Update 2

GeSHi now works. See the test page. JohnBeckett 11:23, September 10, 2009 (UTC)


Thank you for your help on Backspace and delete problems. My problem was a bad mapping, my own fault! I moved our commands into the tip.

Good. JohnBeckett 10:28, 14 June 2009 (UTC)


In our recent new tips discussion I mentioned making VimTip1003 into a generic "file associations" tip. I have done so, after a few hours of work, only to realize right after saving that the original tip (though it seemed rather generic from content) was actually about opening files in an existing Vim instance using the same method given in VimTip1440. Somehow, it would seem I never looked at the title of the tip in all this discussion and planning! I'd like to say that's only what it looks like, not what really happened, but I'm actually not sure...

Anyway, rather than go through more effort to undo my revisions and make a new tip, I have instead opted to rename the old tip. Let me know if you disagree and I can put in the effort to fix things. They aren't too broken – there are links all over the place in the new tip to VimTip1440 – but I'm offering this explanation in case the edit history looks kind of strange.

--Fritzophrenic 03:56, 1 July 2009 (UTC)

Redirecting instead of deleting old tips[]

I see we've had our first known case of a frustrated googler, finding a link to our wiki that is no longer here! I'm sure there have been others, who did not leave a message.

I have restored this tip title as a redirect to the merged tip, but I thought you were going to do that automatically for all the merged tips? I can do it manually, but it sounded like you had a script to do it.

I know this user's frustration! Let's not let it happen again.

--Fritzophrenic 16:21, 21 July 2009 (UTC)

This tip was created on 2009-02-12 with content that was essentially "I use HotKeyz in Windows for assigning key shortcuts" (with a link that is the first hit for "HotKeyz" in Google). Owing to the fact that the only regular contributors here are you and me, it took me quite a while to get around to merging the information and deleting the tip (on 2009-07-19).

If the frustrated itinerant had typed the first two words of the missing title into our search box, the tip they wanted would have magically appeared. I'm not going to try to upset such people, but I'm not going to worry if my idiosyncratic clean-up desires have some negative side effects.

Regarding the issue: Now that I have deleted the around 600 broken titles from October 2007, I agree with your point that when an existing tip is merged, the existing title (even if dubious) should be kept as a redirect to the merge target. I believe I have done that since April. However, we just delete some tips, and those titles disappear. For example, "Beautify Ruby code" was deleted on 2009-07-19 and no longer exists. It contained (quoting from its "dodgy" template): "a very long and complex (and non-VimL) script with no real explanation of why it is needed or what it accomplishes...", so we agreed to just delete it. That will potentially upset some Googlers.

I think the only contentious point concerns the fate of proposed new tips. My feeling (mentioned here) is that I want to keep useful new titles, but do not want to keep not-so-useful titles for merged/moved/deleted new tips. One day I hope to catch up with processing the proposed new tips, so there won't be a long period between creation and deletion. JohnBeckett 01:02, 22 July 2009 (UTC)

Looking for help[]

I have been looking for a place where I can ask questions regarding Vim (I am a new user), but cannot find one.

Basically, I am looking for help on how to install just the console version, on Windows 32-bit and 64-bit computers, manually. I want to do this manually so that I can easily keep syncronised Vim folders on all my OS installations. I also want to know if the console version of Vim can do everything that the GUI version can, or if there are any disadvantages. Also, is Cream irrelevant to the console version?

Could you help me with these question, or advise me on where to ask them? Thanks. Jason404 21:06, 31 July 2009 (UTC)

copied from my talk page, so that the original question and answer would be in the same place

For Vim-related questions, I suggest checking out the vim_use mailing list, or the #vim channel on Freenode as suggested in our community portal. As for this particular question, I do not know if there is a console-only installer out there for Windows. If you find one, please add it to our Where to download Vim page. That being said, the "Cream" link given on that page does include a fully functional console version of Vim. But, gvim has a few features not available in the console. Off the top of my head, gvim has its own keyboard input handling, meaning that it can have maps that are not possible in console Vim, it supports options that are only available with a gui such as 'guitablabel', and the tooltip-style popups. Other than that, I do not know.

Cream is an entirely separate issue. Cream is a particular configuration of Vim that makes it act more like the "point-and-click" editors most people use. I believe that most of its features will work fine in either GUI or console Vim. We talk about Cream a lot mainly because the maintainer of Cream also puts out installers for fully patched Vim on Windows, so that you don't need to compile yourself to be up-to-date. The installer also includes the latest runtime files with every release, so it is a great resource even if you DON'T want the point-and-click behavior.

I hope this helps, I would again highly suggest the mailing list or IRC channel. New users on the mailing list need their first post approved by a moderator before it hits the list, so don't be surprised if it takes a while to show up. Usually it does within a day though. Happy hunting!

--Fritzophrenic 21:52, 31 July 2009 (UTC)

Normally I would not want to answer Vim questions here (see Fritzophrenic's suggestions for questions about Vim). However, this is an issue that we should have a tip on, and I have done exactly what Jason404 wants, so here are some preliminary notes. This is a quick and dirty comment that I may improve and put in a tip later, but bear in mind that I haven't got time to think much now, and I might have forgotten something vital.

For some years I have kept a "bin" directory with my executables, and I copy that to several computers which I regularly use. Directories are: C:\myhome\bin (various simple tools including the following batch file), C:\myhome\bin\vim (I think I used to have my vimrc here), C:\myhome\bin\vim\vim72 and subdirectories (copy of what is installed for Vim). The only Windows configuration on each machine is to set the PATH to include C:\myhome\bin. I also used to set the TMP and TEMP environment variables to a suitable temp directory, but the Windows default should work.

With the following batch file (C:\myhome\bin\vim.cmd), I could type "vim my.txt" at command prompt to start Vim.

:: Set environment variable VIM for the Vim tools, and run Vim.
@echo off
set VIM=C:\myhome\bin\vim
set ARGS=-i %VIM%\_viminfo %*
set x=%1
if not defined x set ARGS=%ARGS% -c "normal `0"
%VIM%\vim72\vim.exe %ARGS%

You can do exactly the same with gvim (have gvim.cmd which invokes gvim.exe).

I do things a bit differently now (and don't have the same need to move around). I now include both C:\myhome\bin and C:\myhome\bin\vim\vim72 in the PATH and do not use the above batch file (typing "vim my.txt" now directly invokes vim.exe). Also, I have a C:\myhome\vimfiles directory and _vimrc and _viminfo are in C:\myhome (my home directory, set in lusrmgr.msc, my user Properties, Profile tab, Local path).

The Download page mentions a portable Vim (for a memory stick), but I have never used it. You get the initial set of Vim files by installing "Vim without Cream" (copy the resulting files; you can then uninstall). JohnBeckett 01:34, 1 August 2009 (UTC)

Status lines[]

Hi John,

One of the regulars of #vim@Freenode, and the author of NERDTree, NERDCommenter and co-author of snipmate, scrooloose, has a lot of nice blog posts about Vim. For instance, he has one about status lines (Making Status Lines that Own) that is really good, and I'm now wondering if it would be a good idea to link to blog posts on the wiki? I realise that there is a chance blog posts may be removed, but the alternative would be to ask him to reproduce the post on the wiki, or ask his permission to do so. What do you think? (Spiiph 10:56, 4 August 2009 (UTC))

I looked at that link and yes, the info looks good. I'd better give you some background: We have had a handful of cases where a new user made a page which essentially said "X is a very useful feature of Vim. Read more at my blog [link]." Some of the contributions were quite a bit longer than that, and contained some useful text, but the key information was at the link. After discussion, we decided to remove that kind of page because there are so many useful or interesting or amusing links that could be added, yet there would not be much benefit: too hard for readers to find, and too hard to maintain, and we all have too many "must read" links already. I moved some of the links to Vim documentation and Vim scripts (which are on the main page).
My guess is that copying stuff from a blog to here might be a bit tricky. Bloggers often don't really want their stuff copied. Also, we are supposed to obtain formal permission for compliance with w:Wikia:Licensing (shown below the edit box).
I would not encourage looking for places to add links to a blog, but I think it would be fine to add a useful link to "See also", when editing a suitable tip. Here are potential candidates for statusline (i.e. we might pick one of these as "the" statusline tip, and add a link to the blog there; we might also copy this list to that tip):
Hmmm. A bunch more things to cleanup! JohnBeckett 12:07, 4 August 2009 (UTC)
Yes, I think a "See also" link is probably best, or alternatively, listing it under an "External links" section, as per Wikipedia. I think that most of the tips you listed above can be merged into "one tip to rule them all", when it comes to status lines. Some of the more obscure or involved tips might merit their own tip, of course. (Spiiph 12:29, 4 August 2009 (UTC))
I don't think we need an "External links" section: with our small number of changes it is easy to check each added link for suitability. JohnBeckett 23:27, 4 August 2009 (UTC)

Thanks for corrections[]

Hi John

I thank you very much, I try to help writing some tips, but as can you see my english skills are very poor, and I'm newbie user of wikis. This is my firt contribution in a wiki.


Hi. Thanks for your message. Actually I'm pretty acquainted with MediaWiki (much more than with Vim!) for I'm involved with several Wikimedia Foundation projects and manage several MediaWiki instances (say,, so if you need help on a specific topic, I may aid. Chikamichi 12:06, September 13, 2009 (UTC)

Date format[]

I notice that the format of the date in the ~~~~ signature has been changed: it used to be "25 April 2008" (day before month) but now it is "September 24, 2009". Only for new posts, though, and the "Preferences" page still has "16:12, 15 January 2001" --Tonymec 02:40, September 24, 2009 (UTC)

The date format issue had a brief mention at w:Forum:MediaWiki 1.15.1 upgrade#Date stamp formatting is broken. I think the Special:Preferences for each user determine the date format in recent changes and history pages. A signature is converted to fixed text, so talk pages will have fixed date formats, and Wikia have switched to U.S. because that's their main source of income (that's my interpretation). JohnBeckett 04:22, September 24, 2009 (UTC)

My skin was taken from under me[]

I used to have the "CologneBlue" skin set in my Preferences, which is the no-nonsense skin I use on every Wikimedia site which allows it (and it is the overwhelming majority of those I browse regularly). I tried the default skin to test that the above comment about the "date format" applied also to it (it does), and now I cannot set it back. HELP!!! --Tonymec 02:40, September 24, 2009 (UTC)

No idea about that – I'll try to investigate later. JohnBeckett 04:22, September 24, 2009 (UTC)
I have a hunch that the Wikia admins have retired everything except Monobook and seven variants of Monaco, except for users who had already selected something else and don't change it. I call that a bug and a regression, or at least removing options because, the guy who removes them says, "nobody uses them anyway" while what he means is "I don't know whether anybody uses it, but I don't use it and I want to drop it". --Tonymec 06:55, September 24, 2009 (UTC)

Advice for really annoying ad[]

I tend to stay logged out of the wiki on my home computers, and whenever I have accessed the wiki for the past couple of weeks, I get the really annoying pop-over javascript-y animated overlay depicted in this screenshot.

Normally I'm OK with ads, but this particular kind of ad is incredibly intrusive, and when I see it on a website, my usual reaction is to stop visiting the site. Yes, it's that bad.

Now, as far as the spectrum of computer nerds goes, I'm probably one of the least opinionated ones out there when it comes to ads on the Internet. I know websites need to make ends meet somehow. But if my reaction is to consider leaving a site, imagine what some of the more hard-core all-software-and-all-Internet-must-be-free-or-else type of people (a group which I'm sure has a sizable representation in the Vim community) would do.

I think we need to get rid of this kind of ad, and fast, if at all possible. I actually think we may lose visitors over this one. I was going to contact wikia about it, but decided to run it by you, first. Is it worth the trouble?

--Fritzophrenic 01:27, September 27, 2009 (UTC)

Uck. It is tricky dealing with these because industry practice is that the web site (Wikia) sells space to some intermediary, which arranges the ads. The official statement is Help:Bad advertisements where you need to report the URL of the bad ad. I am sure this nonsense can be addressed, and I would have noticed any complaints about issues like this at the Wikia forums (so I don't think other wikis are getting this particular problem). Yes, it is essential that we pursue the matter, and please let know what response you get. Note that there may be other examples, and we need to report each case because there is nothing Wikia can do to eradicate these bad ads as a class. JohnBeckett 02:59, September 27, 2009 (UTC)
Well, I heard back from wikia. I was told this was a "targeted ad" that was run on the Technology wikis. They don't run this kind of ad very often, but it sounds as if it will probably happen again. This one in particular has been removed, but it sounds like that's only because the ad campaign is over.
This ad would apparently have been less annoying, except that at home, I have Opera set up to (1) not accept 3rd-party cookies and (2) delete new cookies when exiting the browser. If my settings were different (I don't intend to change them), the cookie left by this ad would have prevented it from appearing more than once per day.
As with other ads, this one would not have been seen by a logged-in user, so we should continue to encourage users to log in, even if they are just visiting.
--Fritzophrenic 13:02, September 30, 2009 (UTC)
The good news is that there was an announcement recently that Wikia had made a profit in the current quarter (I think for the first time). It's clearly not viable for them to provide supported wikis unless making a decent profit. OTOH it's not viable for us to have sliding or obnoxiously animated adverts (I don't mind giving Wikia plenty of time to settle down, but if bad ads become a feature here I am leaving). JohnBeckett 00:55, October 1, 2009 (UTC)
Happily for me, I remain logged-in (until my login cookie expires, and then I log in again), but even so, there is a limit to what kind of ads a user can stomach. Obviously, the kind of ads that makes users go away is not in Wikia's interests. --Tonymec 02:07, October 1, 2009 (UTC)

Tip 1587[]

I believe that this tip (from 2008) is a needless duplication and oversimplification of Setting the font in the GUI and of the paragraph of :help 'guifont' starting at For Win32, GTK, Mac OS and Photon: until (not including) the *E286* tag. In particular, it silently assumes that the user runs on only one platform, which is necessarily one of Windows, GTK1, GTK2, MacOSX or Photon. What do you think? --Tonymec 06:49, November 29, 2009 (UTC)

In general I would agree, but in this particular case I would like to leave the redundant tip as is (while maintaining it, and making sure that it does not expand much more than its current content). The main reason is that the author (Metacosm) runs the #vim IRC channel and (for better or for worse) he wanted to put a bunch of simple tips here for an IRC FAQ and they have links to each tip (see 200802 for the tips). While we could redirect this tip to another, I am sympathetic to the POV expressed to me by Metacosm that some of our tips are too complex: in this case, the user's question would be "how do I change the font in Vim?" and the simple info in the tip quickly answers that for the vast majority of users. The tip has a see also to the main tip saying "details" which would enlighten people who aren't satisfied with the simple tip. JohnBeckett 07:51, November 29, 2009 (UTC)
Hm. "A bunch of simple tips"... I suppose some people will never graduate out of kindergarten (or want to); but then should they use Vim? (Isn't Notepad the right tool for them?) Oh well... Looks like I haven't slept enough recently, I'm not in my normal state of mind. --Tonymec 20:40, November 29, 2009 (UTC)

wiki article/discussion pages[]

On other wiki's I use comments regarding changes made to article pages are usually put in the discussions pages. Sorry I missed the discussion guidelines. 13:01, December 6, 2009 (UTC)

Best Vim Tips[]

"It's hard to know what to do with this tip. I think it should pretty well all be kept, but we should resist the temptation to expand it much"

I expect by "all be kept" you meant 'all be kept as it is' ?

Please notice that the only addition I made was the / (search)

IMHO (please tack this to most of my statments) this, although popular (most likely because of its name), is very confusing. It is a combination of "basic" stuff, really cute tricky stuff and references. As I added to the discussion (before I read you post) having this tip in <Preformatted text makes it difficult to understand as no distinction can be see from comments, sample text and characters in the command. I know most of this wiki was converted from previous plain-text material (A wonderful idea).

Also, as with so many wiki tips, the comments tend to be unhelpful which might be due to an unconscious frustration between describing what the code does and how it does it. This is also very true elsewhere regarding regular expressions. For example:

:set ignorecase : you nearly always want this

This 1) doesn't say what it does, 2) doesn't say why you would want to use it and 3) is a statement of opinion which, I suspect, many users don't share.

Sorry about venting my personal frustration trying to understand this and other Vim tips. Just trying to help.

Hi DG12. You mention several valid points. I have responded at Best Vim Tips. I'll just mention that while you are welcome to talk here, I see every change on the wiki and normally you would just add your thoughts to the Comments section on a tip (you don't need to alert me). JohnBeckett 01:04, December 7, 2009 (UTC)

Search across multiple lines[]

I just added some comments on Tip 242 (as And then saw in the history page that they were recorded "anonymously". I then register. Just wanted to say "hey" I did it. :-) --Pdhackett 09:06, January 24, 2010 (UTC)

Hi Pdhackett. Thanks. I will probably clean VimTip242 up in due course and will try to incorporate your suggestion, although all the possibilities get complicated very quickly. JohnBeckett 01:20, January 25, 2010 (UTC)