That's a good improvement to the template, and you've obviously read our docs because you've improved them too. However, I'm not sure if you've seen the wisdom of Template:Duplicate and Template:Merged.

Tip 706 Make html auto-readable in vim was flagged with {{Duplicate|1005}}. If you think that all useful content from tip 706 has been copied to tip 1005, the correct procedure would be to edit tip 706 and change the "Duplicate" to "Merged" so it reads {{Merged|1005}}.

That will automatically add {{Delete}} (and a reason for the delete, namely that the content has been merged to tip 1005).

If you think tip 706 is unhelpful for current Vim, just flag it as Merged (i.e. you have copied all useful content – there wasn't any). Sometimes when I think it would be useful to add an extra explanation (like what you put in tip 706), I would just type it in, using bold text, at the top (without bothering to improve Template:Merged to accept a parameter because the tip is going to be deleted in a couple of weeks anyway).

When merging tips, I try to merge to the tip that is the most sensible for the current Vim. When there's not much reason to prefer a particular tip, I keep the smaller tip number (it was first).

BTW I would use the "minor edit" flag a little differently. If you flag a tip to be deleted, you have only done a small amount of editing, but it's not really a minor edit. As I understand it, flagging an edit as minor means that other editors can ignore the edit because it's just some inconsequential typo or link fix, etc (something uncontroversial). I wouldn't regard adding a delete template, or even a dodgy template, as minor. --JohnBeckett 05:28, 13 April 2008 (UTC)

Hey there Carpetsmoker! Looks like John beat me to a lot of what I wanted to say (one of these days, John... ;-)), so I'll be brief. I really like what you've done to the delete and dodgy templates! I've been wanting something like that for a sure beats adding the template AND a comment AND something to the candidates for deletion talk page. I also like how well you're embracing the "be bold" policy we like to foster here. We have a lot of tips that can certainly use fixing or pruning! I just had a few things I wanted to mention, and I'll be on my way...most of them John has mentioned already, but I'd like to add that when a tip doesn't work for you, it is often a good idea to discuss it on the tip's comments section, the vim-l mailing list, or an active user's talk page before flagging it dodgy or delete. Most tips here either work for someone or worked at one point in time. Other than that, see John's comments above, and keep up the good work!

--Fritzophrenic 10:13, 13 April 2008 (EDT)

New tipsEdit

I would appreciate help deciding the fate of proposed new tips. If you have a look at Vim_Tips_Wiki:New_tips you will see the idea. Click the 2007 and the January links to see examples of lists of new tips we have previously handled.

We need to process February and March.

February is a bit of a problem because quite a few tips were copied from the IRC #vim web site by its owner Robert Melton aka metacosm. Metacosm had some proposals for the Vim Tips wiki – see the February mailing list archive. (BTW you might like to join that vim-l mailing list.)

I'm thinking of leaving Metacosm's tips for another time. A few of them are weak and/or duplicates of current tips, but I'm not going to do anything brutal with them at the moment. I'm hoping Metacosm has struck a temporary snag and will return here in due course, and I would like to involve him in any pruning of his tips.

It should be fairly easy to decide on the remaining tips. However, I really need someone else so there are at least two people agreeing to keep or delete a proposed new tip. Fritzophrenic has been extremely helpful, but he has let me know that he'll be super busy elsewhere for a while. So, please see if you'd like to offer an opinion on the above February and March pages.

If you want to reply to this message, please do so here. Thanks. --JohnBeckett 05:12, 14 April 2008 (UTC)

Author creditEdit

In VimTip1005, you were presumably trying to be fair and added "and others" to the Author field to indicate that the current tip contains ideas from other people.

As a general rule, I wouldn't bother changing the Author. In some cases, I have added an extra name or two, but that has to be pretty rare. As an example of when I did this, see VimTip1. In that case, the original author's contribution was pretty minimal (essentially "press * to search"), and I merged in tip 5 which had some actual content, so I added tip 5's author (particularly since tip 5 is now deleted, and I had been in email contact with that author about some related issues).

Hundreds of tips have already been extensively modified, and we've kept the original author to acknowledge the person who first went to the trouble of uploading a tip on the topic. It's usually unhelpful to readers, and a waste of time for editors, to track the author. If we want to add "and others" we could do that in Template:TipImported and Template:TipNew (I wouldn't advise that – it's just noise).

I hope you don't mind me adding comments like this from time to time – of course it's only my opinion. One reason I do this is that I might use the material later in some sort of recommended policy document. If you have any doubts or disagreements, please reply here. --JohnBeckett 02:50, 15 April 2008 (UTC)

No, please do add these comments, don't worry about my ego or whatever, I just want to help make this wiki better and more useful.

-- User:Carpetsmoker 13:43, 15 April 2008 (UTC)

Keep the Comments sectionEdit

You improved VimTip1005 and replaced the "Comments" heading with something that was appropriate for the particular comment that followed.

However, we want every tip to have ==Comments== at the end. See the discussion guidelines.

The "Comments" is intended as a small hint to readers that they are welcome to add stuff to the tip (although we will remove fluff in due course – not soon after the comment was added unless it's really misguided, because we want to encourage participation). --JohnBeckett 02:50, 15 April 2008 (UTC)


You marked VimTip1005 as dodgy because the Perl code didn't work on your system. I would take a rather different approach. I'm pretty sure the body of the tip (under "Simple search & replace") does work (not recently tested). Therefore it's not appropriate to label the whole tip as dodgy. Suppose the Perl code does not work. In that case, put a bold para in front of it reporting what you found. If a couple of other people (or one Vim/Perl expert) reach the same conclusion, one of them can just delete that section.

However, the tip is worthwhile (some people want to encode/decode html entities). I would mark a tip as dodgy only if the tip is completely misguided, or has very doubtful content (say a script that could easily accidentally delete stuff), or which applies only to obsolete versions (say a tip on some do-it-yourself spell checker).

BTW I just tried the Perl version on a Windows Vim 7.1 system with +perl/dyn and it worked correctly on the first attempt. --JohnBeckett 02:50, 15 April 2008 (UTC)

Yeah, I didn't have +perl, which is why it didn't work, I recompiled with perl and it worked, do'h.

-- User:Carpetsmoker 13:50, 15 April 2008 (UTC)

VimTip1241 and VimTip505Edit

I agree that it's best to prune out misguided tips, and clearly the body of tip 1241 needs to be deleted. However, before marking it for deletion, I would wonder whether the wiki should have a tip on this topic. If "yes", I would either add a {{Todo}}, or brutally edit the tip.

It would be easy to argue that we don't need a whole tip on the fact that gq} will reformat the next para. However, the whole point of the Vim Tips wiki is that people do overlook gems like that. Consider the poor author who might have spent a whole day writing that pointless script!

I like how you renamed VimTip1005 to just "HTML entities". We might consider making another page with title like "HTML encoding" that is just a link to tip 1005. Then readers have a good chance of finding the useful info. Something like that should probably be done with tip 1241.

I'm inclined to think that a whole (short) tip on gq} probably is worthwhile.

Similar reasoning may apply to tip 505 Email from Vim. I'm not going to argue much for the retention of tip 505, but I will point out that we probably should have a tip on this topic even if it's just a list of links to mail clients that work with Vim. --JohnBeckett 02:50, 15 April 2008 (UTC)

Yes, some tip about gq and related commands would be good, I just assumed it existed because it's so obvious.
But I would be more inclined to make a new tip instead of modifying tip1241, modifying tip1241 would involve deleting all but 6 characters, renaming the page, and changing the category's ... so in effect it would be like making a new tip.

Tip505 just mentions that you can use Vim with pine, I never used pine but most console programs just launch whatever EDITOR is set too ... It's more than obvious that you can set EDITOR to vim in order to use Vim...
For other applications this may not be so easy or obvious, and a tip could be created for those pages...

-- User:Carpetsmoker 03:59, 15 April 2008 (UTC)

Well you have convinced me on tip 505. But please bear in mind my suggestion that we should try to retain the little nuggets of info that are still helpful to Vim 7 users – even the hapless users who think hjkl is silly.

Many readers like to browse tips precisely to pick up some helpful comment. So, I wouldn't try too hard to integrate all comments, and I wouldn't worry if a tip ends up with very little content. Perhaps it will be expanded later. Or in a year we can decide to merge or delete it. But keep useful content while we're still trying to get the tips into a presentable state.

Also, I would far prefer to drastically edit a tip, changing its content and title and categories, than to make a new one. Apart from the "why delete a page and its history, and create turbulence with new tips" factor, it will be a while before I'm ready to give up the VimTipNumber pages, so a couple of trivial points on my mind are that I don't want too many holes in the numbering system, and I don't want the links from the old tips on to break unnecessarily. --JohnBeckett 05:43, 17 April 2008 (UTC)

Oh, I forgot to mention that Tip505 is, with a score of -47, the worst rated tip (literally).
Ehm, anyway ...
Ok, it's a bit of a personal preference, I would be more inclined to just /dev/null "bad" tips and create new ones, it seems easier to me (You could convert a bike to a car, but building a car from scratch would be easier).
Any (well, most anyway) approaches have their ad- and disadvantages, I understand your points and I'll consider them in future edits

-- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)

VimTip827 and VimTip845Edit

Has VimTip827 really been merged to VimTip1312? I don't want to take the time to think about this at the moment (and I'm pretty ignorant in that area), but the following content from 827 looks useful:

XTerm supports 256 colors when compiled with the --enable-256-color configure option. To actually enable the colors set the TERM environment variable to TERM=xterm-256color
Some of the colorschemes, like inkpot, support the 256 color format.

The comment on "256-color terminal for Windows" might also be useful, although I would be quite happy to delete it as it's just a link to a product which presumably could be found with Google if someone needed it.

Also, I'm wondering if the one line from VimTip845 should be in 1312:

setenv TERM xterm-color (and mention the .cshrc for SecureCRT?)

I'm probably being too picky, but I feel I should draw your attention to these issues before you make a final decision. --JohnBeckett 02:50, 15 April 2008 (UTC)

TERM doesn't need to be set to "xterm-256color" or "xterm-color" for 256 colors to work in vim, just "xterm" will work fine in most cases.
I considered adding the --enable-256-color, but most systems enable this by default anyway and (linked in the tip page) also explains this.
In any case, IMHO people should refer to their terminal emulator's documentation to see the notes on 256 color support ... This info could be added but I like to keep tips short and to the point, you can use links to vim helpfiles and/or webpages for more detailed instructions.

The Inkpot colorscheme (and others) and mentioned on this page already.

Why keep the comments about AboluteTelnet? It's borderline spam. There are a number of windows terminal emulators/ssh clients that support 256 colors, in fact I think you will have trouble finding one that does *not* support 256 colors. (And the same applies to terminal emulators for UNIX systems).

.cshrc is a (t)csh startup file, and has absolutly nothing to do with Vim, SecureCRT, or xterm.

-- User:Carpetsmoker 03:59, 15 April 2008 (UTC)

OK I accept what you're saying. In general, however, if it were the case that tweaking something like .cshrc would be helpful to some Vim users, I think it could be mentioned. --JohnBeckett 05:43, 17 April 2008 (UTC)

Ok, I added some generic 256color XTerm notes. -- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)


Hi Carpetsmoker. I see you've moved a few tips and fixed the 'VimTipNr' redirects. That's great. What do you think about the [[Category:VimTipRedirects]] that we have on the end of each one?

They were done by our original admin (User:bastl), but I've been wondering for a while whether they serve any purpose. After the import, the VimTipNr pages were in a dreadful state because many tips did not exist, or were deleted, and a few other things. As part of my bot work, I cleaned them up. The code checks whether each VimTipNr page has the expected syntax. That check expects the content to be on a single line with no redundant spaces.

For completeness, I'll mention that each VimTipNr page appears in one of these:

Anyway, I'm thinking that I should delete all the VimTipRedirect stuff because it is unnecessary, and just causes confusion when editing. What do you think? --JohnBeckett 05:46, 16 April 2008 (UTC)

Yes, I agree we should move away the VimTip### stuff, it is a leftover from the old tip page and quite obsolete now, page titles are much easier to remember, and having two titles for a single page is confusing.

How should we do this? Is it feasible to write a script to do the conversion in one go? Or would it be better to move away gracefully over time?

-- User:Carpetsmoker 12:59, 16 April 2008 (UTC)

I was using the original tip database at and noticed they use VimTip#### links there ...
Why is this database kept online anyway?

-- Carpetsmoker (Talk) 00:54, 17 April 2008 (UTC)

Uh oh. I've caused some confusion. I want to retain the VimTipNr redirect pages. I'm wondering whether there is any reason to keep the category VimTipRedirect on each of the VimTipNr pages.

I suppose that in another year I might rethink this, but having a tip number is a tradition that is often handy. On, the static html can have "Previous" and "Next" links, but we can't hope to maintain navigation links using page titles. Also, the VimTipNr is a convenient shorthand, and makes a short, and easily remembered, URL for mailing lists.

Re My guess is that Bram is going to keep those tips forever (don't know why), so the VimTipNr link that you mention is handy. --JohnBeckett 05:43, 17 April 2008 (UTC)

Ok, Well, the category seems rather useless, so removing it might be a good idea.

I also think it would be a good idea to use titles instead of id's as much as possible, including in templates, the numbers are confusing (title is much easier to remember), and the fact that a page has both a number and name and that both are being used even more confusing.

-- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)

I just deleted the VimTipsRedirect category, and have removed the links to it here. --JohnBeckett 05:27, 18 May 2008 (UTC)

Par text reformatterEdit

The "See also" has a bad link: Text formatting. Did you have something in mind for this? --JohnBeckett 05:46, 16 April 2008 (UTC)

Yes, I was writing this tip but had to go, I will finish it later today or tomorrow.

-- User:Carpetsmoker 10:01, 16 April 2008 (UTC)

Category linesEdit

Many months ago we had an argument about where lines like [[Category:Moving]] should be placed (I'm looking at this in VimTip6).

Someone who knew a lot more about such things than the rest of us was very insistent that category lines should be at the bottom "so you can do category sort overriding". I think that had something to do with the category VimTip that is included by the TipImported template. He also said that the "at the end" rule (with some exceptions) is how Wikipedia does things.

Anyway, I'm not concerned about sort overriding, but we did decide on a convention of placing all category lines at the very bottom of each tip, as described in the category guidelines (mainly so we wouldn't have to make a decision on each page we edited).

I've been wondering about that choice recently because newbies find the category lines to be quite confusing when appending a comment. Perhaps the categories should be just before the ==Comments== line? Then they would not cause distress when someone wants to add a comment.

I think you probably have more wiki experience than the rest of us at the moment. What do you think? It could be argued that it doesn't matter ... but like many Vim users I care about such things<g>. --JohnBeckett 05:13, 17 April 2008 (UTC)

Actually, I added category's to the bottom, this is what wikipedia does and what I'm used to, but I remember reading a page which said that categories should be added at the top, so I started adding them to the top instead.
I can't find the page right now though ... It's of course also possible that I just misread or something...

I don't know about the overriding, but I do know that putting them below the Comments section will make them prone to accidental deletion and/or they will end up in weird places (i.e. in between comments).

And VimWiki != Wikipedia, most pages on wikipedia look very different, so (sometimes) it makes sense to use different formatting guidelines here.

-- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)

Moving pagesEdit

I'm very happy with what you're doing, but I thought I should mention that I have a method for doing bulk renaming of tips. We used this system to rename hundreds of tips. The idea is to prepare a list of proposed changes, then discuss it, then have a bot do the actual renaming and updating of the VimTipNr redirect pages.

Of course mucking about with scripts is never quite as easy as one hopes, so by all means continue making the manual changes you want. However, if you ever want to plan changing lots of titles, you could contact me. --JohnBeckett 05:13, 17 April 2008 (UTC)

Well, moving a page manually is just as easy, but I will keep it in mind for any batch edits later. -- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)

Merging pagesEdit

Your edit of tip 754 Highlighting source between matching curly braces says that it has been merged to tip 6 Moving to matching braces.

I quite agree that however useful the Ruby script might be to some people, it is too esoteric, so I'm quite happy to delete this tip. However, there is useful info in the comments that should be copied to (say) tip 6. I'm not going to try looking at rainbow_parenthesis (links to external pages aren't generally useful IMHO). But the two simple comments at the bottom must be retained somewhere (v% or %v% and vaB or viB). Sure, users should know this stuff, but they don't (and I need to be reminded quite often).

I can see that the two comments don't really tie in with tip 6. So just copy them in as a single comment, something like "You can select the text between braces using the following". No need to polish it at the moment, but keep the info as extra flavour for readers. --JohnBeckett 05:13, 17 April 2008 (UTC)

I added v% to VimTip6, I suppose I could also add %v% but I thought this would be very obvious.
I didn't add vaB and viB to VimTip6 because it's practically the same as %v(%).
I didn't add { } because I personally never found these particularly useful (I always use %).

Of course, feel free to disagree...

-- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)

See also (not See Also)Edit

Perhaps I'm transferring my love of consistency in programs a little too strongly to the wiki, but we sort-of settled on a capitalisation convention of "Titles like this" and not "Titles Like This". Again, it was claimed that "See also" is the preferred Wikipedian way (although no doubt there are many talk pages debating whether "See Also" is better).

Again, I feel compelled to draw this to your attention, and am happy for you to embrace or ignore the suggestion. Sorry if I ever mention it again (but I probably will – I love consistency!). --JohnBeckett 05:13, 17 April 2008 (UTC)

Really? I hadn't noticed. -- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)


That was a good idea to add Template:TipProposed to Launch files in new tabs under Unix. I just want to let you know that I run a bot every now and then to add them automatically (it fills in all the fields, although I would have had to correct the author manually in this case). So don't feel you need to do this. --JohnBeckett 05:13, 17 April 2008 (UTC)

Ok, I suspected something like that, but I wasn't sure so I added it anyway, can't hurt right -- Carpetsmoker (Talk) 07:14, 17 April 2008 (UTC)


Hi Carpetsmoker – With all my other comments, I thought I should clarify one point: It's great having you here! Thanks for all your work. --JohnBeckett 05:13, 17 April 2008 (UTC)

I removed a "dodgy" template you added Edit

Translate_between_single_line_and_block_comments had a "dodgy" template with a reason of "doesn't work" or something similar. I tested the mappings in the tip to try to get them working, and found that they worked as given, so I removed the dodgy template. If the mappings still do not work for you, please list the exact failures in the comments section so that we can improve on the tip. Thanks, --Fritzophrenic 04:21, 13 July 2009 (UTC)

Community content is available under CC-BY-SA unless otherwise noted.