Vim Tips Wiki
Register
Advertisement

New tips June to December 2007

This page is an archive listing tips created from June to December 2007. Please do not edit this page because discussion has finished. If you have any comments, edit the appropriate tip page.

Alternatively, comments can be posted on the mailing list.

Proposed new tip Link Decision
$ instead of 4 discuss Keep
Automatic Commenting of Preprocessor Directives in C discuss Keep
Automatically Update Copyright Notice in Files discuss Keep
Automatically add ifndef ... to a C header file discuss Merged to VimTip514
Automatically create and update cscope database discuss Keep
Automatically fitting a quickfix window height discuss Keep
Changing all HTML tags to lowercase discuss Keep
Check your syntax files for configurable options discuss Keep
Create patch for currently editing file discuss Keep (with todo)
Decrease chances of file corruption in case of computer crash discuss Keep
Displaying the current Vim environment discuss Keep
Dosini folding discuss Keep (with todo)
Easy Buffer Switching Without a Plugin discuss Keep
Exchanging adjacent words discuss Keep (fixed)
Fast jump to next variable on the same line (php programmers ) discuss Keep (with todo)
Fix errors that relate to reading or creating files in the temp or tmp environment on an MS Windows PC discuss Keep (with todo)
Format javadoc discuss Keep (with todo)
Formatting paragraphs in LaTeX: an "environment-aware gqap" discuss Keep
Get the most out of the latest Vim Editor with Hacking Vim! discuss Merged to Vim documentation
Hide dos lineends discuss Merged to VimTip26
Icomplete discuss Deleted
Improved Hex editing discuss Keep
In line copy and paste to system clipboard discuss Keep (with todo)
Increase/decrease fontsize using a map ala FireFox discuss Merged to VimTip760
Keep your vimrc file clean discuss Keep
Key maps using the Alt modifier discuss Keep
Learn to do it by hand! discuss Deleted
Make MRU plugin open files in tabs discuss Deleted
Making CapsLock work in Vim discuss Keep (with todo)
Map cut copy and paste to Windows defaults discuss Keep (with todo)
Mapping keys in Vim - Tutorial (Part 1) discuss Keep
Mapping keys in Vim - Tutorial (Part 2) discuss Keep
Mkdir on edit if needed discuss Keep
Open Filename with "gf" discuss Deleted
Search and replace in all buffers discuss Keep
Search keywords in c function discuss Keep
Search keywords in c++ function discuss Deleted
Set gvim window size discuss Merged to VimTip88
Set options or named registers with let discuss Keep (with todo)
Short help for PHP functions inside of Vim discuss Deleted
Show parts of line that make it longer than 80 chars discuss Keep
Swap LHS and RHS of an Assignment statement discuss Keep
Swap file "..."already exists! - so diff it discuss Keep
To switch back to normal mode automatically after inaction discuss Keep
Use :next to search for files in the current directory discuss Keep (with todo)
Version Control for Vimfiles discuss Keep
Vim Doclet discuss Keep
Vim On Vista discuss Keep (with todo)
Word frequency statistics for a file discuss Keep
X11-clipboard support in terminal discuss Merged to VimTip984

Please add your comment (sign with --~~~~) below the appropriate heading. Use ---- between comments.

General comments (not for a specific tip)[]

There was too much work required to do all the fixing that we had hoped to achieve before assigning a tip id (tip number) to these tips. Therefore I have added a "to do" comment to relevant tips, summarising discussion on this page. I should be able to upload an edited version of the tips we are keeping, with tip id and possible "to do", within a day. --JohnBeckett 04:20, 19 February 2008 (UTC)

$ instead of 4[]

Simple tip with a simple mapping. It's useful and adaptable enough to be not TOO bad, though. It does need to be fixed - the imap given will just insert some text - but other than that, I'd probably keep it.

--Fritzophrenic 15:29, 8 January 2008 (UTC)


Keep this. It's cute. Have you got enough time to fix the imap? --JohnBeckett 02:14, 9 January 2008 (UTC)


Automatic Commenting of Preprocessor Directives in C[]

Very clever and well-commented function - the author can be proud. It could prove very useful, and illustrates some clever things you can do with the :s command used inside a function. I'm a little worried that it may not be very adaptable to other ideas, and that the illustration of Vim concepts may be hidden by the script, but I'd keep this one. It is not overly complex, and the code is well-explained enough through comments that people may be able to glean some new ideas out of it as well as using it as-is for a useful tool.

--Fritzophrenic 15:29, 8 January 2008 (UTC)


Keep this. I have to note that I hate the kind of superfluous comments created by the tip! However, it's a big world and I know some like them, particularly on long ifdef/endif. --JohnBeckett 02:14, 9 January 2008 (UTC)

Automatically Update Copyright Notice in Files[]

Disclaimer: I submitted this tip.

I like this tip a lot and it has proved very useful to me. It does a good job highlighting use of the :g and :s commands, strftime function, BufWritePre autocmd event, and use of an option's value in an if statement (&modified, to be exact). Unlike other complex regular expression example tips, this tip explains in detail exactly what each part of the regex does.

However, I can see why somebody might not like it, because it is fairly complex, probably not very commonly needed, and there are already similar tips:

This tip should probably be merged into one of these, because it does do a much better job explaining the regex, and I really like the use of the :g command.

--Fritzophrenic 19:19, 7 January 2008 (UTC)


Keep this. Merge 97 and 890, but don't merge this with them (result would be too complex). Include a link "See also" (not "See Also") in each.

--JohnBeckett 02:14, 9 January 2008 (UTC)


Automatically add ifndef ... to a C header file[]

More explanation for the implementation needs to be given, but assuming it works, this tip could be very useful. It looks fairly simple, using mostly basic commands, so explaining it shouldn't be difficult. As noted on the tip, however, a better thing to do would probably be to merge it into VimTip514.

--Fritzophrenic 15:29, 8 January 2008 (UTC)


Let's be brutal and delete this. Add its content (which I haven't checked) to VimTip514. BTW this tip is not "automatic" - you have to press a key (a good thing IMHO). --JohnBeckett 02:14, 9 January 2008 (UTC)


Automatically create and update cscope database[]

Keep this. Haven't checked it, but it has history and looks good. --JohnBeckett 02:40, 9 January 2008 (UTC)


Keep, if it works. I don't use cscope so I'm probably not going to check it. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Automatically fitting a quickfix window height[]

Keep this. I edited the tip to put Fritzophrenics' arguments in (min,max) order. Change if you like. --JohnBeckett 02:40, 9 January 2008 (UTC)


Keep this. It works and is pretty useful, especially if you use vimgrep. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Changing all HTML tags to lowercase[]

This tip lists 2 complex regexes with no explanation that are simple enough to be written from scratch when needed. I think this tip is an excellent example of a useful application of the substitute command, but I don't think it teaches anything new. I remember seeing the exact same sort of thing in another tip, used as an example to illustrate a point, though I can't remember where I saw it, and it converted to uppercase rather than lowercase.

I recommend deleting this one.

--Fritzophrenic 19:19, 7 January 2008 (UTC)


I think you underestimate your regex ability. I imagine there are many Vimmers who would struggle to reproduce this tip, and since it does something that at least sounds useful, I'm inclined to keep it. I totally agree that the tip is horrible with no explanation. However, we've got plenty of mystery tips, so I would just add a todo to this, and hope that one day I could get someone from vim_use to add a brief explanation. --JohnBeckett 02:14, 9 January 2008 (UTC)


Hmm...I've taken a closer look. The first regex is (in my opinion) overly complex for what it accomplishes, but still fairly simple. This is where I stopped looking the first time - my mistake, because the second one is where things get interesting. It is complex enough that I had to try it out to convince myself that it actually works (which it does, although the description is slightly misleading). I can certainly see your point...it would probably take me some time to reproduce these, and they use some advanced concepts that many Vimmers would not think to use or even know how to use. If these concepts were brought to the foreground of the tip, I'd probably like it better.

So, here's my take:

I don't like tips that simply post a clever regex or script, with no real explanation. I especially don't like such tips when the problem solved by the regex or script is a simple one that doesn't really need a complicated solution, or if the problem is a very specific one. This particular tip is probably useful to many people, and the problem solved is much more complicated than it first appears, so after a more complete look I actually kind of like it. I can certainly see the value in keeping it, especially when the regular expressions are explained, simplified, and improved (as they will be - this is a wiki!), but this and other similar tips have the potential to become VERY widespread. I can't count the number of times I've written a complex regular expression to accomplish a complicated task. But, the true value isn't the final regex, it's knowing how to write it. So, what if we create a category to contain tips such as this one that are primarily just examples of complicated regular expressions? It would be a place to go to look for specific pre-solved problems, a place to browse a bunch of examples of advanced concepts to spark your own ideas, and a place for people like me to shuffle new tips off to so that we don't immediately cry "delete!" for a tip that many would see value in. We have a "searching" category, but I think this category is better used for very general tips about searching, perhaps with specific illustrative examples. I think that an "Advanced Regex" category or a "Regular Expressions" category would be a good place for tips like this one, that give regular expressions for a very specific purpose, probably constructed over a long period of time and tweaked again and again, intended for later reuse.

--Fritzophrenic 15:52, 9 January 2008 (UTC)


Good idea (to create a suitable category). I agree with your point that a tip with nothing but a regex is pretty useless and irritating. I added your "Advanced Regex" or "Regular Expressions" category to my local todo file and intend looking at it further. You can do it now if you like, but I was going to think a bit more about what tips would go in which of these. The "Regular Expressions" doesn't quite sound right because such a category should probably be about explaining regexs in some detail. So I favour "Advanced Regex" but was going to look for some more examples before implementing it. --JohnBeckett 03:36, 10 January 2008 (UTC)


I agree with your distinction between an "advanced regex" and a "regular expressions" category. I'm going to go ahead and implement the "advanced regex" category - there are a few tips I want to add to it already. We can sort out the details later. I also like the idea of a "regular expressions" category to include tips with more general help with regular expressions, but that is a category that warrants further discussion.

--Fritzophrenic 17:42, 10 January 2008 (UTC)


Excellent - I think it's a good result. --JohnBeckett 04:13, 11 January 2008 (UTC)


Check your syntax files for configurable options[]

Disclaimer: this a tip I submitted!

I wrote this tip when I learned about it from the unrelated Auto-fold Perl subs tip. Somebody wrote a complex function for doing syntax folding of Perl scripts, which (although clever) is completely unnecessary because the functionality is built-in already. It just happens to be disabled by default, and the author (and myself) did not realize that it was there, because they did not first check the syntax file for configurable options!

--Fritzophrenic 19:19, 7 January 2008 (UTC)


Keep this. --JohnBeckett 02:14, 9 January 2008 (UTC)


Create patch for currently editing file[]

Probably keep. --JohnBeckett 02:40, 9 January 2008 (UTC)


I'm not entirely sure what this tip is for, but I understand it enough to know it could be useful. I say, fix it up to explain what it does better, comment the script better, and improve the title, then keep it.

--Fritzophrenic 19:59, 11 January 2008 (UTC)


Decrease chances of file corruption in case of computer crash[]

Keep. Needs a comment about the OS, but if Yakov thinks it's ok, I would keep it (but what a hack!). --JohnBeckett 02:40, 9 January 2008 (UTC)


This sure is a clever one! Definitely keep. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Displaying the current Vim environment[]

Keep. This was discussed on vim_use. --JohnBeckett 02:40, 9 January 2008 (UTC)


Not sure how useful this tip is, but if it has been discussed, I won't argue. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Dosini folding[]

Flag to fix later (add explanation or delete). --JohnBeckett 02:40, 9 January 2008 (UTC)


Agreed. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Easy Buffer Switching Without a Plugin[]

Dodgy. Surely there's a better way of doing this? I've forgotten the name of what I use, but it's better than this. --JohnBeckett 02:40, 9 January 2008 (UTC)


I think keep. I just use the buffer menu in gvim for this, but if you want a keyboard-only solution this works fine. Tip needs cleanup but I think it is okay. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Exchanging adjacent words[]

Let's keep this. Delete most of the comments. Add "See also" to/from VimTip47. --JohnBeckett 02:40, 9 January 2008 (UTC)


Agreed, but let's put it in the "Advanced Regex" category. Now that there is a good explanation of how it works, I suppose it could go in "Regular Expressions" since the only really advanced thing in it is the %# atom (which I learned from this tip!) --Fritzophrenic 19:59, 11 January 2008 (UTC)


Fast jump to next variable on the same line (php programmers )[]

Probably keep. Maybe rename to "Fast jump to next PHP variable on the same line". --JohnBeckett 02:40, 9 January 2008 (UTC)


I don't like it, but I guess it's not a bad tip, so go ahead and keep it. The keys used are already mapped, as mentioned, but that can be fixed. For myself, I just use f$ the first jump, then ; and , for any subsequent jumps. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Fix errors that relate to reading or creating files in the temp or tmp environment on an MS Windows PC[]

Flag to fix later (add explanation or delete). --JohnBeckett 02:40, 9 January 2008 (UTC)


Agreed. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Format javadoc[]

This was originally not a tip, but a request for help. I know the usual policy would be to delete this, but I made a comment that almost fixes the problem brought up. If somebody can fix up my general method, it might make a good tip.

--Fritzophrenic 19:19, 7 January 2008 (UTC)


I think there's too much work required to fix this, and would be inclined to terminate it. Perhaps, with the large number of new tips we are currently trying to sort out, we need a way to flag a tip as "not yet ready to be made a full tip; may delete if it's not fixed before May 2008". Then we could apply that to this tip, move on, and satisfy us both. --JohnBeckett 02:14, 9 January 2008 (UTC)


Agreed. Flag to fix or mark dodgy. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Formatting paragraphs in LaTeX: an "environment-aware gqap"[]

Keep this. No idea if it is valid, but it looks good. --JohnBeckett 04:13, 10 January 2008 (UTC)


I think this tip should be fixed to use options to control what counts as a paragraph, rather than using a mapping. Fix and keep. I don't know anything about LaTeX though, so I'm not the guy for it... --Fritzophrenic 19:59, 11 January 2008 (UTC)

Get the most out of the latest Vim Editor with Hacking Vim![]

Put this on a "dodgy" list. I think there is a list of Vim books somewhere (if not, we should make one). We could move some brief content from this tip to that page. After a couple of months, this tip is going to be useless and should be deleted without first being given a tip id. Hmmm, I'll even put a link to the "Vim books" page on the Main Page. --JohnBeckett 05:00, 10 January 2008 (UTC)


Agreed. It's practically an advertisement. --Fritzophrenic 19:59, 11 January 2008 (UTC)


Hide dos lineends[]

Merge any useful content into VimTip27. Delete. --JohnBeckett 04:13, 10 January 2008 (UTC)


I agree with the deletion, not with the merge destination. There are probably some "get rid of DOS linefeed" tips out there to merge to, but even those are suspect. See my comment in the tip. --Fritzophrenic 23:47, 11 January 2008 (UTC)


Explaining my previous comment:

I finally found where I think you meant to merge this. Did you mean VimTip26: Change end-of-line format for dos-mac-unix? If so, I would be good with the merge, but only if the caveats I mention in the tip comments are merged as well. I suppose there MIGHT be a good reason to want to hide the mismatched line endings without fixing them.

BTW, the method used in this tip is similar to VimTip241, where it is used to do something entirely different. We might want to link this tip if we end up merging rather than deleting.

--Fritzophrenic 22:38, 14 January 2008 (UTC)


Sorry - yes, I meant tip 26. So we agree to merge anything useful to VimTip26 with a reference to VimTip241 for a similar method for a different purpose. --JohnBeckett 00:23, 14 February 2008 (UTC)

Icomplete[]

Delete. I was going to suggest keeping it, but the URL leads to the author's site which says that the utility is no longer supported and one of the vim.org scripts should be used. --JohnBeckett 04:13, 10 January 2008 (UTC)


Agreed.--Fritzophrenic 23:47, 11 January 2008 (UTC)


Improved Hex editing[]

Keep this. Haven't checked it, but it looks good and we don't have an xxd tip. --JohnBeckett 04:13, 10 January 2008 (UTC)


Agreed. I actually made this one, and can vouch that it works. Haven't found anything screwy with it so far (though I'm not guaranteeing that there isn't anything). --Fritzophrenic 23:47, 11 January 2008 (UTC)


In line copy and paste to system clipboard[]

Put on dodgy list? I can't bring myself to study the tip at the moment, but surely its content should be merged into one of the other attempts to subvert Vim's copy/paste? Note that VimTip1199 and VimTip1306 claim to be related to character-wise pasting. --JohnBeckett 04:13, 10 January 2008 (UTC)


I'd agree to the dodgy, but this tip concerns Mac OS X copy/paste. Apparently this user has trouble integrating with the system clipboard for that OS. I'm guessing there's an easier, option-setting way to do this, since Vim integrates so well with every other OS I know of, but I can't be sure. The tip needs some major cleanup to better explain what it is useful for (it isn't until the end of the tip that OS X is mentioned). This tip needs to be verified to see if it is necessary and working as well. --Fritzophrenic 23:47, 11 January 2008 (UTC)


Increase/decrease fontsize using a map ala FireFox[]

These are similar: VimTip414, VimTip760. Not sure. --JohnBeckett 04:13, 10 January 2008 (UTC)


Ugh...I see why you had problems.

I'd say, merge this tip and the comments about changing font size from VimTip414 into VimTip760. Tip 414 deals with changing the entire font, not just the size. Possibly see whether this tip or something similar (like the very first comment in Tip 414) can replace the function in Tip 760, or if the function is needed for non-Windows systems.

--Fritzophrenic 22:38, 14 January 2008 (UTC)


I have merged to 760, and marked 414 and 760 as duplicates for fixing later. --JohnBeckett 00:23, 14 February 2008 (UTC)

Keep your vimrc file clean[]

I like this tip a lot. I didn't write it, but I could have! It gives good advice about keeping your settings for your vimrc file in places that make sense, making your changes modular, and keeping your vimrc nice and uncluttered.

Keep it!

--Fritzophrenic 19:19, 7 January 2008 (UTC)


Keep this. --JohnBeckett 02:14, 9 January 2008 (UTC)


Key maps using the Alt modifier[]

Keep, I suppose. --JohnBeckett 05:00, 10 January 2008 (UTC)

Learn to do it by hand![]

I'd delete this one. Although it is good advice, it is not really very useful. Would somebody ever search for this? The tip title is the entire content of the tip.

--Fritzophrenic 22:38, 14 January 2008 (UTC)


Agreed. --JohnBeckett 00:23, 14 February 2008 (UTC)

Make MRU plugin open files in tabs[]

We'll have to keep this in view of the author! But shouldn't there be a link to MRU? Also, fix typo "auther" to "author". --JohnBeckett 05:00, 10 January 2008 (UTC)


If you don't like this tip, I would not be sorry to see it go. It is something I stripped out of the comments from another tip that I was cleaning up. I couldn't find a place to put it in the tip itself, so I created a new tip to hold it. I have never used the MRU plugin and have no desire to use it, but I imagine that it has been fixed by now to handle tabs. If not, this tip may be useful with some cleanup. But don't keep it on account of me.

--Fritzophrenic 15:11, 10 January 2008 (UTC)


OK I see how it happened. I have just emailed Yegappan (author of MRU.vim) to ask if he would comment on the idea in this tip. Subject to Yegappan's thoughts, I'm inclined to delete the tip. --JohnBeckett 04:13, 11 January 2008 (UTC)

Making CapsLock work in Vim[]

Good grief! Surely no one has to write that much uppercase text that they need 26 mappings? I hate the idea of deleting a tip that has been written in English, is properly formatted, and has an author. Maybe label it dodgy? BTW I suspect the "Mixed" function should just unmap the keys rather than mapping them again (I wonder what Vim does with 'imap a a'?). --JohnBeckett 05:00, 10 January 2008 (UTC)


I actually like this tip! This is one of my most common mistakes in Vim. Leaving CapsLock on when I leave insert mode is a huge headache...I'll hit <esc>jjjjj, which ends up joining a huge block of code with my accidental JJJJJ. Oh, crap! Better hit uuuuu...except U is not at all what I need! I thought long and hard about using this tip, but decided that hitting something other than CapsLock to turn on CapsLock is not something I wanted to do, nor do I want (or have permission, at work) to get that AutoHotKey program mentioned.

I recommend keeping this tip, with a todo item of figuring out a Vim-only solution that allows use of CapsLock via the CapsLock key without using an external program, but also keeps CapsLock off in normal mode.

Oh, and rename the tip to "Disabling caps lock in normal mode"

--Fritzophrenic 22:38, 14 January 2008 (UTC)


IMHO this tip needs too much work to be useful for your stated need. However, I'll just put some comment in it and keep it. --JohnBeckett 00:23, 14 February 2008 (UTC)

Map cut copy and paste to Windows defaults[]

We need to do a proper tip on this. See VimTip960, VimTip1387. I don't like this new tip. It's just a q&d workaround for those not familiar with how to use Vim. I guess we could just mark it dodgy as a reminder that we need a tip with a sensible discussion of the fact that there are good alternatives in Vim to Notepad style editing, with good advice on mappings for those that want a Notepad life. Or just delete the tip? --JohnBeckett 10:14, 10 January 2008 (UTC)

Mapping keys in Vim - Tutorial (Part 1)[]

Keep. --JohnBeckett 05:00, 10 January 2008 (UTC)

Mapping keys in Vim - Tutorial (Part 2)[]

Keep. --JohnBeckett 05:00, 10 January 2008 (UTC)

Mkdir on edit if needed[]

Dodgy. I didn't study it, but I suspect any modern Windows would work simply with mkdir and no '-p'. It's a cute tip, but it worries me. At first it sounds clever, but in practice you would end up making typos and creating directories when you thought you were doing something totally different. In fact, I'm inclined to delete it, but a "dodgy" status would give the author some notice of my concern. --JohnBeckett 05:00, 10 January 2008 (UTC)


Will keep tip because it has some nice code. Have inserted a comment with my concern from previous para. --JohnBeckett 10:11, 14 February 2008 (UTC)

Open Filename with "gf"[]

This tip needs to be removed. First of all, there are already 2 tips (marked as duplicate on this tip) which highlight the same functionality. Secondly, it accomplishes with a mapping something already built-in to Vim. Third, it overrides a common function with this mapping.

Let's get rid of this one.

--Fritzophrenic 19:19, 7 January 2008 (UTC)


Agreed. Delete this. --JohnBeckett 02:14, 9 January 2008 (UTC)


Search and replace in all buffers[]

Keep. Tips is a bit simple, and is probably covered elsewhere, but we need something on bufdo, and this is a start. I added the comment about how I think you need "bar" rather than pipe. I would prefer using 'hidden' rather than the misguided :update, but it's a big world. --JohnBeckett 10:14, 10 January 2008 (UTC)

Search keywords in c function[]

Keep, assuming it works. --JohnBeckett 10:14, 10 January 2008 (UTC)


I just looked at this more closely. It definitely works and is very cute, in fact I couldn't resist tweaking it. This tip will feature in "did you know", or maybe even be a "featured tip", although it should get a bit more polishing first. It wipes the 'a' register, and needs a few more lines of explanation.

The tip should be renamed (it works for C and C++). Maybe "Search within a code block or function". --JohnBeckett 07:58, 12 January 2008 (UTC)

Search keywords in c++ function[]

Merge into above Search keywords in c function tip. Pointless having two tips. BTW I was amazed when this tip appeared because it successfully uses "C++" in a title. When I tried that (to rename the tips broken by the import) I got a complete disaster. Maybe it works now. --JohnBeckett 10:14, 10 January 2008 (UTC)


I just looked at this more closely. The content is rearranged, but is identical with the preceding Search keywords in c function new tip, so I have flagged this (c++ version) as Delete. --JohnBeckett 07:58, 12 January 2008 (UTC)


Similar things can be accomplished with text objects combined with the Search and replace in a visual selection tip. A "See also" is in order.

--Fritzophrenic 22:38, 14 January 2008 (UTC)


Set gvim window size[]

Delete. Should improve VimTip88 by clearly stating that you can control the initial size of the gvim window with a simple command in vimrc. Also, maybe rename tip 88 to make it clear the content discusses more than just maximizing the gvim window. There is an official todo link under Recent changes and Categories in the Participate frame which appears on the left in the monobook skin. Maybe we should add all these "should do this and that" notes to the todo page, possibly with content from the tip, then delete the tip. --JohnBeckett 10:14, 10 January 2008 (UTC)

Set options or named registers with let[]

I'm going to keep any tip by Fritzophrenic, but I don't get the point of this one, although that doesn't matter. The tip might be tweaked: In the "duplicate the setreg function" code, I think there should one example showing a register being set to "example". I would replace "E.g." with "For example,". Why does " = 1" have spaces but "=0" doesn't? How about a reason for why "Setting Options" uses let rather than set and setlocal. --JohnBeckett 10:14, 10 January 2008 (UTC)


I agree we should keep this one, but I think it certainly needs cleanup. Here's why I made it:

I was just starting my Vim use, and discovered that macros can not only be recorded, but also constructed and shoved into a register. I searched long and hard for a way to initialize a few registers to contain prebuilt macros from my vimrc file. Finally, I stumbled on the setreg function, only to find to my dismay that setreg does not exist in Vim 6, which is the version on a Unix server I use every so often, with the same vimrc files. After you pointed out that "let" can be used to set register values, I investigated further, and figured out that "let" can also be used to set options, which I had until then only set with "set." Armed with this knowledge, I was able to create far more advanced scripts, constructing option values dynamically, setting options to the value of variables, etc. It was a tidbit of information that I just had to share - surely, there were others like me that just assumed "set" was for options, "let" for variables, and that was the end of the story. Could the tip have been better named? Could it include better examples? Most definitely. But I think it could prove very useful for beginning Vim users...possibly even a good addition to your "did you know..." section. Like, "Did you know...you can modify the value of almost everything with the 'let' command?" That's what I was trying to get across...proper use of 'let' can be very useful in any advanced script, and Vim, while a great editor with spectacular help files, is unfortunately so full of commands that it is hard to master more than a very small subset of them unless someone points you in the right direction.

--Fritzophrenic 15:44, 10 January 2008 (UTC)


Quite an inspiring explanation! When you have time, please see if you can tweak the tip a bit and remind me to add it to "did you know". --JohnBeckett 04:13, 11 January 2008 (UTC)


Short help for PHP functions inside of Vim[]

Delete. I would want a good reason to keep this tip. I'm not happy about deleting it, because it may be useful to someone. But should each of the 2,000 scripts have a tip that is nothing more than a link to the script? --JohnBeckett 10:14, 10 January 2008 (UTC)

Show parts of line that make it longer than 80 chars[]

Disclaimer: I heavily edited this tip at one point (though I had forgotten this until I checked the page history).

This tip is a great example of fixing a common problem as well as highlighting an uncommon Vim command. I may have been over-zealous in my editing, so somebody may want to restore some of the previous content, but I'd say KEEP THIS TIP!

--Fritzophrenic 19:19, 7 January 2008 (UTC)


Keep this. --JohnBeckett 02:14, 9 January 2008 (UTC)


Swap LHS and RHS of an Assignment statement[]

Dodgy or delete? I have probably never wanted to change "alpha = beta" to "beta = alpha". Does someone really need this sufficiently often to make a mapping? Maybe add content as a note in Exchanging adjacent words. Or maybe include content in a tip "Amazing regexs with no explanation". --JohnBeckett 10:14, 10 January 2008 (UTC)


Delete or shuffle off to "Advanced Regex". It is sufficiently different from Exchanging adjacent words that it probably shouldn't be merged.

--Fritzophrenic 22:38, 14 January 2008 (UTC)


I'll have to keep it because someone on the Vim mailing list wanted this function! --JohnBeckett 00:23, 14 February 2008 (UTC)

Swap file "..."already exists! - so diff it[]

Keep. Should fix title – maybe "Handling the Swap File Exists error". We do need a tip on this, so this is a good start. If anyone remembers, I notice that "If there where" should be "If there were". --JohnBeckett 10:14, 10 January 2008 (UTC)

To switch back to normal mode automatically after inaction[]

Keep for its cuteness. Rename (at least omit "To"). Maybe "Automatically switch back to normal mode" (is "after inaction" needed?). --JohnBeckett 10:14, 10 January 2008 (UTC)

Use :next to search for files in the current directory[]

I suppose this should be kept, although I'm doubtful. I would never use a command like this because the alternative tools are so good, starting with the built-in :Explore. Sure, if I want to open *.h in one directory I might use a Vim command, but I can't imagine in practice wanting to open all matching files in a tree without actually using a tool better suited to the job. Anyway, if there's no better place to put this content, I suppose we can keep it.

To fix the tip: The help should be to :next_f rather than :next. The "for example" confuses me. For one thing, there is no reason to have an example with "vim" in the path. Also, delete the "d:" – it serves no purpose. Does the command really search the parent directory like the words suggest? --JohnBeckett 10:14, 10 January 2008 (UTC)

Version Control for Vimfiles[]

This tip is a good idea, and something I hadn't thought of even though it may be obvious to some. But, it doesn't really have much to do with Vim. I'd keep it, but wouldn't be heartbroken to see it go.

--Fritzophrenic 19:19, 7 January 2008 (UTC)


Keep this (although I agree that it would be no loss to see it go). --JohnBeckett 02:14, 9 January 2008 (UTC)


Vim Doclet[]

Keep. --JohnBeckett 10:14, 10 January 2008 (UTC)

Vim On Vista[]

I have Vim installed on Vista, and it seems to be working fine with none of the hacking this tip suggests. It may be useful for others (I certainly wouldn't want to figure all of that stuff out) but someone needs to find out:

  1. Is this tip needed? Does this problem actually happen on a regular basis?
  2. Does this tip work?
  3. Is there a better way? Preferably a simpler one?

--Fritzophrenic 19:19, 7 January 2008 (UTC)


I'm a bit worried about this tip. It starts by explaining that some unknown problem occurred, and then lists the fairly extreme steps taken to recover. My worry is that the tip could be interpreted as advice that should be followed by general Vista users. I know the first para is intended so readers should not reach that conclusion, but it would be an understandable mistake.

In fact, it's not clear if the author ever established what the problem was, or which of the listed steps were necessary. In these kind of confusing one-off situations, it's not clear to me that the steps taken by one person are of much value to general readers, unless some explanation is provided (a particular problem was noted, and its cause was found to be X, and because of reason Y, the workaround was Z). Pretty well all of the steps look dangerous to me, starting with the source chosen to download Vim.

Also, George Reilly just confirmed Fritzophrenic's point that installing Vim on Vista does not require any of the steps in the tip. See the vim_use archive.

--JohnBeckett 09:36, 8 January 2008 (UTC)


If no one supports this tip soon, I'm inclined to delete it. --JohnBeckett 02:14, 9 January 2008 (UTC)


I didn't realize that everything was working that well on other machines. I do think there is value in keeping two of the sections:

  • The information on how to fix the shell extension if Vista thinks vim needs to be run as administrator.
  • The file association fix.

Where would you recommend putting these? Or are they too edge case for the wiki?

--Fuzzymonk 16:27, 14 January 2008 (UTC)


I'll have another look and think about whether to recommend delete. --JohnBeckett 00:23, 14 February 2008 (UTC)

Word frequency statistics for a file[]

Keep. A pointless but truly amazing tip! Put it in the proposed "Advanced regex" category. --JohnBeckett 10:14, 10 January 2008 (UTC)

X11-clipboard support in terminal[]

Keep. I don't want to take the time to think much now, but I note that VimTip984 is related.

Interesting how the http link to sad.png now shows up as a link, whereas when the tip was created it showed the actual image. We should delete that link. BTW I am deleting smileys from tips and comments, when I find them. --JohnBeckett 10:14, 10 January 2008 (UTC)


Advertisement