Vim Tips Wiki

New tips June 2008

This page is an archive listing tips created in June 2008. 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 Current consensus
Commenting with opfunc discuss Keep
Errorformats discuss Keep
File no longer available - mark buffer modified discuss Keep
Get the correct indent for new lines despite blank lines discuss Keep
Incremental search under cursor discuss Merged to VimTip979
Highlight multiple words discuss Keep
Open multiple files, each in a new window or tab discuss Merged to VimTip888
Quickly switch between pager-like and editor-like scroll discuss Keep
Restore screen size and position discuss Keep
Showing syntax highlight group in statusline discuss Keep
Toggling HEX-editing on/off via Shortcut (using xxd) discuss Merged to VimTip1518
Using vim color schemes with Putty discuss Keep
Yank to the end of line with Shift-y instead of y$ discuss Merged to VimTip979

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

General comments (not for a specific tip)[]

I think we need to make sure to add appropriate categories to every new tip before officially accepting it, or they may never get added. Maybe make a policy of this. --Fritzophrenic 19:45, 29 July 2008 (UTC)

A good idea, but is it achievable? Until we have determined a framework for categories, I think we can only add the easy ones like "Folding" or "Searching". --JohnBeckett 12:04, 30 August 2008 (UTC)

Commenting with opfunc[]

This looks good. I'll try and test it soon; then it should be good to keep. I might replace the ',' leader with the default '\'. Perhaps there should be a see also between this and 1555 Creating new text objects. I suppose there are lots of other ways to comment code (that might work in Python) -- see 271 Easy (un)commenting out of source code, but this tip should be kept to illustrate opfunc (new one on me). --JohnBeckett 12:23, 4 July 2008 (UTC)

I think the biggest value of this tip is as an example of how to define an operator. It should be kept but with enhancements in that direction. Some of the enhancements I'd like to see are: explain what is meant by "treating commenting just like deleting"; mention that many commands operate on a range which is given to them through a motion command; mention that is one of the fundamental idioms in vim usage; explain what opfunc= and g@ do; explain what the variable args in DoCommentOp are and why they are ignored.

Other than that a worthwhile tip in my opinion.

--BenArmston 21:54, 6 July 2008 (UTC)

I agree; fix and keep. Also link to other tips that use opfunc, such as my recent tip on creating an "a fold" text object, and whatever page of the "mapping keys" tutorial mentions it. --Fritzophrenic 19:45, 29 July 2008 (UTC)

Keep This tip was good, but a little mysterious. I have done a major reword that I hope makes it clearer. While trying to understand it, I couldn't resist refactoring the script. Perhaps it should be a featured tip? --JohnBeckett 02:46, 2 September 2008 (UTC)


Isn't this one a bit of a red herring? People should be primarily directed to learn about the :compiler command, not mess with 'efm'. Only if there isn't something available for their compiler should they worry about this. Sightless 06:34, 3 July 2008 (UTC)

So, let's make this a tip about the :compiler option, and how to add a new compiler if yours doesn't exist. The hardest part of writing a compiler plugin is getting the errorformat right.

Many people are probably not even aware of 'errorformat' or :compiler. This is a good place to help them learn. Also, if you have tips on figuring out whether your compiler is supported, this would be a good place to put them methinks.

Perhaps the tip does need a rename though, if we change its focus.

--Fritzophrenic 13:43, 3 July 2008 (UTC)

Here are some related tips (four of these are already in 'see also').

I'll try and think about this some more another time. --JohnBeckett 12:23, 4 July 2008 (UTC)

476 Errorformat and makeprg seems to be the most generic tip on this to date, so I would recommend merging Errorformats into it and then enhancing 476 Errorformat and makeprg to become a more complete tip about the :compiler command and compiler plugins.

Broadening the topic slightly, the other tips listed above should probably be merged into one per language, e.g., one tip listing all the compiler options for various different Java compilers (if the Java compiler plugin shipped with Vim doesn't contain these already.)

Whatever is done, I'd like to see an explanation of what %f, %l, %c and %m in the remaining tip(s).

--BenArmston 13:27, 9 August 2008 (UTC)

Keep We have to move on, so I have put a long wishlist in the tip mentioning the points above. I also tried to ensure that all tips on errorformat or makeprg or compiler are in Category:Compiler so they are easier to find. A lot of cleaning up (probably severe pruning) is required, but this new tip is good to keep in my opinion, and I don't think anything more will be done with it soon. --JohnBeckett 11:57, 2 September 2008 (UTC)

File no longer available - mark buffer modified[]

I think this one's good enough to include, but not sure it's fully matured yet; I have found the message isn't really eye-catching enough; maybe it isn't always displayed. Sightless 06:37, 3 July 2008 (UTC)

Great tip, but rename perhaps? The tip covers every value of v:fcs_reason, so it is far more generic than the title would indicate. On the other hand, the primary purpose of the tip is exactly what the title says; it mostly just asks the user what to do, except in this case. --Fritzophrenic 13:43, 3 July 2008 (UTC)

Keep tip. I can't think of a better title and searching for 'fcs_reason' finds this tip, so it's probably ok as is. --JohnBeckett 12:23, 4 July 2008 (UTC)

Keep tip. I haven't tried it yet, but I do like the idea. The title seems fine to me. --BenArmston 22:08, 6 August 2008 (UTC)

Yeah, I think it's good enough to keep. I think it always does work; I just don't see it sometimes. But it's easy enough to make the message more prominent if desired. I'll amend the tip to note how to do this for others like me to like a more obvious warning. Sightless 15:05, 30 August 2008 (UTC)

Get the correct indent for new lines despite blank lines[]

I wrote this one, but not sure how many people have tried it/tested it. I'm not even sure I have it installed myself yet (though I do intend to use it!) I have tested it, but it might be smart to wait a little before releasing it, just so it's had more testing. Sightless 06:46, 3 July 2008 (UTC)

I haven't tried it either, but the concept is a good one, and the functionality is needed. It needs testing, then probably update the function to use prevnonblank(), but keep it. --Fritzophrenic 22:29, 3 July 2008 (UTC)

Keep. --JohnBeckett 12:23, 4 July 2008 (UTC)

I haven't tried it either as all of the indentexpr I use handle blank lines well. As such I was a little confused by what this tip was trying to accomplish, so I'd recommend enhancing the introductory paragraph to be a little clearer on why Vim sometimes gets it wrong. Also replace x<BS> with <left><right> as it doesn't mess with the . command. And use prevnonblank().

Other than those I'd recommend keeping. --BenArmston 13:45, 9 August 2008 (UTC)

Agree with BenArmston's suggestions, but I'm also aware that this has bugs. In fact they are severe enough that I had to disable it (didn't have time to debug it). I will try to enable it again some time soon and improve it, since the consensus seems to be to keep it, but it it likely to take me a while. Sightless 15:05, 30 August 2008 (UTC)

Incremental search under cursor[]

I have to admit, I really don't see any purpose behind this one. I don't really care whether this stays or goes. Someone obviously felt they needed this functionality, so I'd lean toward keeping it. --Fritzophrenic 22:29, 3 July 2008 (UTC)

Likewise I don't think I'd find a use for this, but it's pretty cute! To do this, I would use use 'v' then move to the right, then press keys I have mapped to search for the selected text (escaped so it works). I've been working hard to merge some of the search tips, so I'm a bit reluctant to take a new one. Later, I'll see if there is anywhere good to put this info. If not, I would keep it in a new tip, although I could be talked out of keeping it because it really only works "incrementally" if the search target is on the same screen. --JohnBeckett 12:23, 4 July 2008 (UTC)

I also don't see any purpose behind this tip. As John points out, the cursor position never moves when using this mapping, so the only use for it seems to be to highlight matching terms which are on the same screen. I suppose after sufficient text is included, one could page up and down in the text, or use n and N. But this seems a long winded way of getting there. Visually highlighting the region and then using mappings to search for that seems a better solution to me: Search_for_visually_selected_text.

Perhaps we should put a comment on the tip asking the author to clarify how he finds this tip useful. If the author doesn't answer and no-one else can think of a reasonable use case for this tip, then I think it should go.

If we do keep it, for whatever reason, I'd like to see it enhanced with a map to reduce the search i.e., <C-h> removes the last letter added to the search. --BenArmston 11:48, 10 August 2008 (UTC)

Merge to Short mappings for common tasks. --JohnBeckett 12:04, 30 August 2008 (UTC)

Merge complete. --JohnBeckett 05:31, 3 September 2008 (UTC)

Highlight multiple words[]

Problems, problems! I suppose that keeping this as a short example of a nice trick would be worthwhile. OTOH the tip would just end up irritating me because while it offers an easy way to highlight words, there is no method given to unhighlight them. By the time you cleaned it up, you might have the complexity that is no doubt in the script referenced in the comment. Perhaps tip could be rewritten for a quick intro to match, 2match, matchadd() etc. A couple of tips mention 2match, but only for a specific purpose like highlighting multiple whitespace. I think any serious use of this feature would make one want to use the referenced script. --JohnBeckett 12:23, 4 July 2008 (UTC)

I'd suggest leaving this one for a while and seeing if anyone fixes it up, probably using some or all of the techniques I suggest in my comment in the tip itself. If nobody has fixed it, I'd be okay with deleting it, although perhaps we should mention the script on our scripts page. --Fritzophrenic 19:45, 29 July 2008 (UTC)

I don't think this tip would necessarily get too complicated if it were fixed up to use matchadd() and then to use matchdelete() to remove the highlighting. An introductory paragraph or two to matchadd() etc would certainly benefit the tip. I'd put a todo section in the tip formalising Fritzophrenic's suggestions in the comments and then wait to see if it's fixed. --BenArmston 12:02, 10 August 2008 (UTC)

We've got too many TODO items, and it's been over two months since Fritzophrenic raised questions in a comment on the tip. If no one fixes this within a week, I suggest it should be deleted. I would put a link to the plugin mentioned in the comments on the scripts page. --JohnBeckett 12:04, 30 August 2008 (UTC)

I've decided to take this as a challenge ;-) and have started to fix this tip. I should have something worth reconsidering in a few days. --BenArmston 23:02, 1 September 2008 (UTC)

Keep Very nice result! I'll add a couple of comments to the tip. --JohnBeckett 03:57, 2 September 2008 (UTC)

As agreed with BenArmston on the comments of the page, I have changed the title (and fixed links here). The original title was "Multiple Hilighted Search" (but it highlights, and doesn't search). --JohnBeckett 00:17, 6 September 2008 (UTC)

Open multiple files, each in a new window or tab[]

Surely the 'in-vim' commands are obsolete and ':args' and ':sall' and ':tab sall' should be featured most prominently (along with command-line arguments). As the tip says, merging would be best for this. Sightless 06:34, 3 July 2008 (UTC)

I don't do this kind of thing enough to be really sure whether this tip adds anything, but I suspect that Sightless is correct again, and that ':args' etc should be more fully explained in VimTip888 (the duplicate mentioned in this tip). So I favour merging at the moment. --JohnBeckett 12:23, 4 July 2008 (UTC)

The difference between using :args and then :sall, for example, would be if you already had a bunch of buffers open in a certain configuration of windows/tabs, you might not want to open _all_ of them. I think this fact should be explained, and I also think the tip should be merged as indicated. The merge tip needs to be cleaned up. I do like the method used in the merge tip (though the method in this tip is probably more efficient) simply because the concept of using Vim to send a command to the console to in turn send a command back to the same Vim is a fun one. --Fritzophrenic 19:45, 29 July 2008 (UTC)

Merge complete (mentioned points above and merged to VimTip888; needs more work). --JohnBeckett 05:31, 3 September 2008 (UTC)

Quickly switch between pager-like and editor-like scroll[]

Extremely simple tip. I suppose it could be useful to someone, though I can't think of any occasion where I'd feel that I need it. I also have j and k remapped to gj and gk, so I wouldn't like using it as-is. I think the best option would be to find somewhere to merge this into, but I can't think of where it would go. I'd be fine with keeping this if we can't find a better place for it. I'm only hesitant because of my somewhat strict "we can't showcase every possible mapping in Vim" attitude. --Fritzophrenic 19:45, 29 July 2008 (UTC)

Possibly merge to one of:

I'll check these later. Any thoughts? --JohnBeckett 12:04, 30 August 2008 (UTC)

Keep I slightly reworded the tip to clarify what it does. It's quite a nice idea and I couldn't find any good place to merge the tip, so I plan to keep it. I added a todo with links to several (mostly dodgy) related tips. --JohnBeckett 05:12, 4 September 2008 (UTC)

Restore screen size and position[]

This one has some bugs, so I suggest deferring it for a while until it matures. The first script on the page doesn't really work unless you never open multiple Vims simultaneously (the original non-servername-based one would have worked, but the version currently there does not), and the second one I recently discovered has a bug: it clobbers your unnamed register. There may well be others. Needs a bit more work/polishing before featuring. Sightless 06:34, 3 July 2008 (UTC)

Once it works, I'm pretty indifferent. It seems quite a complicated/script heavy tip, but we have a few of those. Perhaps it would do better as a plugin, though? --Fritzophrenic 22:29, 3 July 2008 (UTC)

I don't want to keep the tip unless it shows some insight, or is helpful as is (without obvious bugs), or it is likely that it will be fixed soon. We have too many TODO items to leave loose ends IMHO. I have posted to vim_use recommending that if we don't fix the tip now, it should be deleted. --JohnBeckett 12:04, 30 August 2008 (UTC)

I've fixed the clobbering unnamed register bug. I suggest removing the first alternative. I believe the second is superior and ready for prime time. I said on the mailing list I had disabled this: I hadn't. It has been working flawlessly for me ever since it was written, except for the register clobbering, which is now fixed. I probably will disable it, as it messes with my workflow on some rare occasions, but that's no bug in the script! Sightless 15:05, 30 August 2008 (UTC)

I have added a third version of the script which has the slight advantage that it uses readfile()/writefile() to access the data file, and so does not mess up any MRU file or buffer lists. I intend to leave all three versions for a few days to see if anyone wants to comment. If none, I'll clean it up in maybe a week. I haven't given it a great test, but it sure seems to work, and looks good for people who like that kind of thing. --JohnBeckett 12:04, 9 September 2008 (UTC)

Showing syntax highlight group in statusline[]

I think this one's a goer! Sightless 06:46, 3 July 2008 (UTC)

Really cool tip. Let's keep it. Possibly merge into Identify the syntax highlighting group used at the cursor, but probably better to just put a see also in each tip. --Fritzophrenic 22:29, 3 July 2008 (UTC)

Keep. In some ways a merge would be good, but I prefer to keep these two separate, with 'see also' in each. --JohnBeckett 12:23, 4 July 2008 (UTC)

Haven't read the tip but also think it's a great idea and a keeper, so if the details are quality let's do it! Sightless 15:05, 30 August 2008 (UTC)

Actually, judging from the first comment, I must have read it... But I forgot... Oops. Sightless 06:03, 31 August 2008 (UTC)

Toggling HEX-editing on/off via Shortcut (using xxd)[]

Merge the tips and check for subtleties such as endofline, binary, etc. Should use a buffer not global variable, as was discussed on the mailing list recently. Sightless 06:39, 3 July 2008 (UTC)

Someone should look and see if there is anything to merge and do so, but Improved Hex editing covers the content of this tip in much the same way, and is more developed. --Fritzophrenic 13:43, 3 July 2008 (UTC)

I think we should reword some of the intro text about general editing in hex format using xxd, and then insert this into Improved Hex editing. That is really all that needs merging, after which we can delete this new tip. --Fritzophrenic 19:45, 29 July 2008 (UTC)

Tip has been merged to VimTip1518. --JohnBeckett 12:04, 30 August 2008 (UTC)

Using vim color schemes with Putty[]

I've made some modifications but haven't tested. Could others? See comments at the bottom of the page. Sightless 06:37, 3 July 2008 (UTC)

An anonymous user posted that it worked. I also tried it, and it worked for me (although my system worked with colors before the tip, so all I could confirm is that the changes by Sightless do make the settings change as expected for a PuTTY terminal, and the colors continued working with the new settings). Therefore, I have removed the todo and I'm happy with the tip. Except, I added a 'see also' and a bit more thought may make us want to merge this tip into the first 'see also'. --JohnBeckett 12:23, 4 July 2008 (UTC)

If it really does work, let's keep it and decide later whether to merge. We can always put the merge marker on it. --Fritzophrenic 19:45, 29 July 2008 (UTC)

Yank to the end of line with Shift-y instead of y$[]

The quality of the tip is good. Is it worth keeping, though? It's a very simple tip, and there seem to be numerous opinions on whether it's truly useful! Given that, perhaps people would benefit just as much from a simple friendly introduction to the :map command (which surely is already a tip?)! Sightless 06:43, 3 July 2008 (UTC)

I agree with pretty much all of this. It is a high-quality tip, a good idea (the behavior of Y has always bothered me because it is so different from C and D), but it doesn't really demonstrate or accomplish anything nontrivial. I'd feel great including this particular mapping as an example in another tip, and I wouldn't mind keeping it, but do we really need it? I don't think we should have a tip for every mapping anyone has ever thought up, but where do we draw the line? --Fritzophrenic 22:29, 3 July 2008 (UTC)

Would someone please tell me if <s-y> is subtly different from Y? I wonder if we could rename this to something generic like "Useful mappings" (or "Useful maps" might be better for searching the tips?). Then we could put any other small tips that are essentially just a suggestion for a mapping here? I would like something more significant than the tip as it now reads. --JohnBeckett 12:23, 4 July 2008 (UTC)

I would move content of 979 Map search key to space bar to "useful maps" (and delete 979). --JohnBeckett 11:51, 6 July 2008 (UTC)

I like this idea, because I don't like deleting all the simple-but-useful maps (like <F3> for :cnext<CR> for example) but they don't make much of a tip on their own. How about a "Short mappings for common tasks" or something like that. We need to emphasize that the task must be common, and the mapping short (80ish characters or less), to be on such a page. Anything more complex or uncommon should probably have its own tip. --Fritzophrenic 19:12, 29 July 2008 (UTC)

Not worth keeping as an entire tip, but worth having in a useful maps tips. Emphasising commonness and shortness in the tip title seems a good idea. --BenArmston 12:08, 10 August 2008 (UTC)

I think this should be merged to Short mappings for common tasks. If we keep all tips of this nature, we'll end up with an unusable haystack. --JohnBeckett 12:04, 30 August 2008 (UTC)

Merge complete. --JohnBeckett 05:31, 3 September 2008 (UTC)