New tips April 2008
This page is an archive listing tips created in April 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 |
---|---|---|
Comfortable handling of registers | discuss | Keep |
Creating new text objects | discuss | Keep |
Creating your own syntax files | discuss | Keep |
Filter buffer on a search result | discuss | Keep |
IPython integration | discuss | Keep |
Launch files in new tabs under Unix | discuss | Keep |
Mapping keys in Vim - Tutorial (Part 3) | discuss | Keep |
Move current window between tabs | discuss | Keep |
Open content of website in new buffer (using elinks text web browser) | discuss | Merged to VimTip127 |
Open file in new tab if current buffer is non-empty | discuss | Flagged to delete |
Overload a key with multiple handlers | discuss | Keep |
Provide script-accessible version info in your plugins | discuss | Keep |
Remap join to merge comment lines | discuss | Keep |
Using bash completion with ctags and Vim | discuss | Keep |
Please add your comment (sign with --~~~~
) below the appropriate heading. Use ----
between comments.
General comments (not for a specific tip)[]
Comfortable handling of registers[]
Keep. Think about a better title later (unless someone can suggest a better title now). --JohnBeckett 11:19, 6 May 2008 (UTC)
Keep, rename later. FIRST though, use a different key for the mapping! 's' is a command that many people use quite frequently! While we're at it, use nnoremap instead of map. --Fritzophrenic 13:50, 6 May 2008 (UTC)
I've fixed the mappings. A possible title may be "Cycle registers for easy access" --JohnBeckett 12:09, 9 May 2008 (UTC)
Creating new text objects[]
Keep, excellent. Don't merge with Indent text object which uses tricky code that obscures the fundamental issues. I'll put a "See also" to "Indent text object" and to VimTip1516 (I'll look later to figure out where). I might mention what the <C-U> does in the vnoremap. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. --Fritzophrenic 13:50, 6 May 2008 (UTC)
Creating your own syntax files[]
Keep, good tip. I will clean up the comments. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. --Fritzophrenic 13:50, 6 May 2008 (UTC)
I think the couple of remaining comments can stay there for now, and the tip is great and ready to keep. --JohnBeckett 12:09, 9 May 2008 (UTC)
Filter buffer on a search result[]
Keep. Has some interesting points, although I'm beginning to strongly dislike tips where you have to guess what they do. Also, I don't understand that stuff at the end where the author uses nmap ,f ...
instead of nmap <Leader>f ...
although there is some complex stuff mentioned about g:mapleader
. If someone can briefly enlighten me please do so. Also, I'm beginning to think we should change all tips (where appropriate) with 'nmap' to 'nnoremap' (no-remap, and spell it in full). --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. I actually like the "see also" links better than the tip itself, but whatever. Also, here be the mysterious "CloseScratch" function mentioned in another tip. --Fritzophrenic 13:50, 6 May 2008 (UTC)
We should indeed just use <Leader>f
(I don't see the point in the discussion about g:mapleader ; I suspect the author didn't fully understand how <leader> is meant to be used).
I also have trouble with tips (or whatever) that don't start by explaining in two sentences max what they are all about. Isn't this tip about another way to do a :vimgrep
?
--Luc Hermitte 11:42, 7 May 2008 (UTC)
Thanks for noticing "CloseScratch". I hate how this tip has one version, and the other tip has a different version, for no apparent reason. I prefer the other version (in fact I'm pretty certain that the line normal! "<Esc>"
in this tip is wrong and redundant). I will clean up the CloseScratch function, and change the maps like this <Leader>f
.
Using :vimgrep
of course requires that you have saved the buffer. I think that the technique shown in this tip of copying arbitrary lines to a scratch buffer is worth keeping. --JohnBeckett 11:22, 8 May 2008 (UTC)
I have reworded the tip, improved the script, and fixed the mappings to use <Leader>. I think it's quite nice now. --JohnBeckett 12:09, 9 May 2008 (UTC)
IPython integration[]
Keep, but with changes:
I removed the autosaving stuff, we already have a tip for that: Auto save files when focus is lost.
I don't have KDE so I can't test this, but it looks like it send a command to konsole from vim?
This would seem useful, but this would of course work for more stuff than just IPython, IMO this page should be renamed to something more general like 'Launch commands in konsole', examples with IPython and other applications can be added at the bottom.
-- User:Carpetsmoker 21:09, 15 April 2008 (UTC)
I'd suggest making a "see also" section then, with a link to the auto-save tip and other python integration tips (I think there was an omnicomplete python tip recently, among others).
--Fritzophrenic 15:15, 15 April 2008 (UTC)
I don't see why the auto-save tip should be linked, it's a very separate subject/tip.
I also don't see the relevance of other python tips if we would make this a general 'Launch commands in konsole' tip.
-- User:Carpetsmoker 21:09, 15 April 2008 (UTC)
I agree with Carpetsmoker (don't bother linking). I don't like the fact that the reader is expected to guess what the tip is all about, but I don't think we're going to be able to fix it now. So keep it, and hope it is fixed later. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. --Fritzophrenic 13:50, 6 May 2008 (UTC)
Is it meant for the Category:Integration ? (I have no idea what IPython is) --Luc Hermitte 11:46, 7 May 2008 (UTC)
While I think working on the categories is important, I'm not going to worry about it until things settle down. I suspect that deep thought on the categories is required. However, I will mention that I'm not sure what benefit there is to the Integration category. I can't imagine searching for this tip using that category. --JohnBeckett 11:22, 8 May 2008 (UTC)
Launch files in new tabs under Unix[]
I was thinking of merging all the "Launch files in new tabs" tips, there are now about 5, and 80% is the same... -- Carpetsmoker (Talk) 18:41, 1 May 2008 (UTC)
That would be great. I've make a todo list of tips on launching Vim in case it is any help. Please add anything I've missed. I put whatever I could find so some may not be completely applicable. Perhaps move them to another list, or just delete them. --JohnBeckett 06:04, 2 May 2008 (UTC)
I actually disagree. While it is certainly a good idea to merge tips that have redundant content, in some cases I believe it is much better to have several smaller tips, each covering a small aspect of some greater whole, possibly each referencing each other, than one huge tip that covers everything. For example, the new tip about creating text objects could be covered (and is briefly mentioned) in the "Mapping keys in Vim" pages. However, I think it is much nicer to be able to view a short, simple, to-the-point tip that covers exactly what you want to do, rather than needing to wade through one big tip that covers everything remotely connected with what you are trying to do. If I wanted one big resource, I'd just use the Vim help files. I think the point of a tip is to be simple, not encyclopedic.
I think we should have several tips about launching Vim. Perhaps (and I'm doubtful about this) we could merge all the "launch in new tabs" tips to cover all OSes. Personally I don't think we should, simply because there are so many OS-specific tweaks to cover that will be totally useless to people with other OSes. We certainly should NOT, in my opinion, merge in tips about hacking the Windows registry to get the context menu to work, or using the SendTo menu, or other topics that (while related) are a separate enough topic to deserve another tip. Obviously it is a good idea to link to these other tips, but again, this is a collection of tips, not an encyclopedia.
--Fritzophrenic 14:20, 2 May 2008 (UTC)
Keep, although I haven't tried it. I will fix the spelling. Presumably the line "Be aware that the desktop file are exchanged every time you install a new version of Gvim" should be "Installing a new version of gvim will probably overwrite the gvim.desktop
file, so you will need to repeat the following change".
I agree with Fritzophrenic that we should not merge tips unless there is a real benefit. I'm pretty sure that a tip on this topic for Windows would not nicely integrate with a similar tip for Linux. Such integration would just give a complex mess. The list I made on Vim_Tips_Wiki:Todo was intended only to help merge tips that are essentially duplicates, where you would only need to take a couple of paras from one tip and put it in the other, and that change would not greatly expand the scope of the merged tip. So this new tip for Unix should not be merged with the existing tips. --JohnBeckett 11:19, 6 May 2008 (UTC)
If the tips are not merged, at least they should have a very close title. (Integration category is missing) --Luc Hermitte 11:56, 7 May 2008 (UTC)
The tips will have a "See also" referring to each other. --JohnBeckett 11:22, 8 May 2008 (UTC)
I've fixed the wording and typos, and added the "See also" in the Unix and Windows tips. --JohnBeckett 12:09, 9 May 2008 (UTC)
Mapping keys in Vim - Tutorial (Part 3)[]
Keep, great stuff. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. Perhaps rename to get rid of "tutorial" as suggested in the comments for one of these tips? I think "Guide" would be a better description than "Tutorial". --Fritzophrenic 13:50, 6 May 2008 (UTC)
"guide" is a good suggestion. May be we should see this with Yegappan. --Luc Hermitte 11:59, 7 May 2008 (UTC)
Yegappan went to a lot of trouble to prepare those three mapping tips. If he wants to call it "tutorial", that's fine by me. We could ask him what he thinks about "guide" (and that is a good word), but I think a cost/benefit analysis suggests it's just not worth the bother. I could easily produce a list of 200+ tips that have really bad titles. --JohnBeckett 11:22, 8 May 2008 (UTC)
Move current window between tabs[]
Keep. Potentially useful and shows some interesting code that is not too long. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. This is fairly cool. --Fritzophrenic 13:50, 6 May 2008 (UTC)
Open content of website in new buffer (using elinks text web browser)[]
Merge to one of the tips I listed in "See also", probably VimTip127 (Paluh, the author of the new tip, seems to agree that would be best). When it is merged, need to copy in the "See also", with a todo that more merging is needed. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. --Fritzophrenic 13:50, 6 May 2008 (UTC)
Hi,
I've added comment to the 127 Preview HTML files quickly which is my proposition of merge. I've got one additional proposition: after merge this tip should have new title (maybe "Open html file/website in new buffer (using snapshots from elinks or lynx)" but I'm not sure if it's not to long ;-)).
--Paluh 11:01, 7 May 2008 (UTC)
Thanks Paluh. I'll wait for a few days to see if you plan to actually merge the content that you copied to the end of VimTip127 (it really needs to be merged so there is just one tip; there may be some points which are difficult to merge – they can be put in a comment). Your proposed title is far too long and is unnecessarily complex. The title should not mention the technique (for example, in six months there may be a new tool which does the job much better, and we would update the tip to use that tool). I'll think about a good title later. --JohnBeckett 11:22, 8 May 2008 (UTC)
Ok. Thanks for your help!
--Paluh 07:15, 9 May 2008 (UTC)
Open file in new tab if current buffer is non-empty[]
Delete? It was good of Fritzophrenic to keep the info somewhere while cleaning up VimTip1285, but I don't think this merits a separate tip (unless Fritzophrenic can explain further). --JohnBeckett 11:19, 6 May 2008 (UTC)
Go ahead and delete it. I was just cleaning up the other tip and really didn't find this functionality useful, advisable, or even correct. --Fritzophrenic 13:50, 6 May 2008 (UTC)
Overload a key with multiple handlers[]
Keep, I suppose. It's good to have a tip on the concept of chaining handlers, although I'm not sure that I'll ever need it. OTOH it's irritating how the tip refers to "the CloseScratch function used in another tip of mine", and the author hasn't responded to my request to clarify what that means. --JohnBeckett 11:19, 6 May 2008 (UTC)
CloseScratch is in one of the tips above. I like this tip...probably never will use it, but it's a cool way to remap keys without losing functionality. That way I can stop complaining about people remapping , and ; all the time. _ I can understand, because it's really only useful on a Dvorak keyboard where it appears on the home row. Anyway...keep! --Fritzophrenic 13:50, 6 May 2008 (UTC)
Very nice tip. However, I really have troubles with Category:Map BTW, IIRC, there are a few other tips about scratch buffers. --Luc Hermitte 12:04, 7 May 2008 (UTC)
I kind of like the Map category because this is a tip about a way to map the same key to multiple things. Can you suggest a better category? --Fritzophrenic 12:27, 7 May 2008 (UTC)
Better? I don't know. I think this raises a broader question regarding the relationship between Scripting and Map categories. I write and maintain a lot of scripts, and this tip implements a complex scripting feature that would have been useful to me more than once. Which has nothing to do with tips about simplistic Usage mappings (e.g. VimTip1541), or tips about tweaking our keyboard (VimTip1528, etc).
Because of these later kind of tips, we can't move Category:Map into Category:Scripting -- moreover this would hide Mappings tips within another category. May be the simpliest solution is to add this tip into both categories. --Luc Hermitte 12:42, 7 May 2008 (UTC)
To me, category Map means a tip with information about mapping, or a technique to implement a map (so this tip should be in category Map). I'm not sure about category Scripting. Lots of tips have a few lines of script. What good would it be to put them all in that category? I think the Scripting category should be for tips about scripting. --JohnBeckett 11:22, 8 May 2008 (UTC)
I have slightly reworded the tip, and improved the script. I also added a note that I think the tip needs a realistic example of when it might be useful. However, I think it's good enough to keep as is. --JohnBeckett 12:09, 9 May 2008 (UTC)
Provide script-accessible version info in your plugins[]
Keep. It's a very simple tip (simple for those who write plugins), but it's a good idea, and may be expanded with more relevant info later. --JohnBeckett 11:19, 6 May 2008 (UTC)
I agree. Very simple, but a subtle difference from the norm that lets you write plugins that can be far more useful. --Fritzophrenic 13:50, 6 May 2008 (UTC)
Remap join to merge comment lines[]
Keep, good stuff. I'd need to have a lot of comment joining to do before I went to the trouble of applying this tip, but it does have some good ideas that will be useful to someone. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. I have been doing a lot of comment joining...that's why I wrote the tip. A nice side-effect was realizing I could use it for line continuations in Vim as well. --Fritzophrenic 13:50, 6 May 2008 (UTC)
Using bash completion with ctags and Vim[]
Keep (not tested). It's more of a bash tip than a Vim tip, but it may be helpful to readers, and I'm happy for a few tips to deal with specialist topics. --JohnBeckett 11:19, 6 May 2008 (UTC)
Agreed. --Fritzophrenic 13:50, 6 May 2008 (UTC)