Vim Tips Wiki:New tips/200805

New tips May 2008

For each proposed new tip:

• Is it worth keeping as a separate tip?
• Should it be merged into an existing tip? Which?
• If it should be kept, is it ready for release? Which points need fixing? Should it be renamed?

Please edit this page (not the talk page) in the appropriate section below the following table.
Alternatively, comments can be posted on the mailing list.

Proposed new tip	Link	Current consensus
Beautifying plain text in Vim	discuss	-
Create new subroutines	discuss	-
Less.bat : Now less is more on Windows, too	discuss	-
Return to previous indent	discuss	-
Twitter	discuss	-
Use eval to create dynamic templates	discuss	-
Vim setup to edit MoinMoin wiki files	discuss	-
VimBlock - Numblock mode for Vim	discuss	-

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

Tips linking to external sites

Here are some rambling thoughts on how we should handle tips whose main purpose is to link to an external site (tips that rely on an external site for content). If we get consensus, I might convert this to a guideline.

On the original vim.org tips site, before the Vim Tips wiki, there was no way to update tips: incorrect or inadequate information couldn't be fixed; related tips couldn't be merged; obsolete or unhelpful tips couldn't be deleted. As a result, we still have many defective imported tips (although we have made considerable progress merging, deleting and fixing tips since the import in June 2007).

Most of our editors have accepted the point of view that radical pruning is required to merge helpful material, and to delete unhelpful material. Just the fact that we have a large number of tips (1250) makes finding useful information difficult.

While clean-up continues slowly, we have agreed to carefully consider new tips before they are added. The procedure, and examples of past practice, can be seen on the new tips page. Since the import, we have accepted 58 new tips, deleted 7 proposed new tips, and merged another 10 proposed new tips (that is, 17 tips were not accepted).

General agreement has been reached that it would be best for tips to have substantive content: a tip should be self contained; a reader should find useful information in the tip; a tip should not depend on another site for the main content.

We have rejected at least two tips that did little more than link to an external site. The main problem with such tips is that once a precedent is set, there is no limit to the number of such tips that could be written. There are over 200,000 hits for vim tutorial in Google.

We rejected a tip that consisted of a link to a script on vim.org with the comment:

A tip should do more than link to some interesting feature. There are perhaps 2000 Vim scripts – it would not be helpful to have a tip linking to each.

See the Create a new tip page for guidelines.

The tips proposed for May include:

• Beautifying plain text in Vim
• Less.bat : Now less is more on Windows, too
• Twitter

Each of these raises concern because their main purpose is to link to useful information on another site. If tips have a low quality, or the linked external information is unhelpful, I would quickly recommend their deletion because most readers already have too many links to handy sites.

However, I am not happy to recommend deletion of these proposed tips at the moment. Instead, I am wondering if each could have additional information added so a reader would feel that they had learned something, just from reading the tip.

An alternative may be for us to have a new feature on the Main Page with some kind of Announcements section. The tips above would be good choices for a temporary page (with at least six month's lifetime) that would highlight interesting features available on external sites. See also the brief discussion on my talk page.

--JohnBeckett 05:35, 27 May 2008 (UTC)

Beautifying plain text in Vim

See the tips linking to external sites discussion above.

Keep, but first fix. See my suggestions on the tip. --JohnBeckett 00:44, 2 June 2008 (UTC)

---

Create new subroutines

Keep, but first fix. Need to clarify that the "__xxx__" stuff is for a Perl program. Fix the script using Fritzophrenic's suggestion in the Comments. --JohnBeckett 00:44, 2 June 2008 (UTC)

---

Why not. It is not much different from the tips that show how to insert C header-gates. --Luc Hermitte 12:34, 4 June 2008 (UTC)

---

Less.bat : Now less is more on Windows, too

See the tips linking to external sites discussion above.

I haven't had any feedback from the author since alerting Ewfalor to my dilemma. If the tip hasn't been greatly generalised before the end of June, I think we should delete it and move the link to an "Announcements" and/or "Information" page, as outlined earlier. --JohnBeckett 00:44, 2 June 2008 (UTC)

---

Update: Ewfalor has replied on his talk page. Let's see how it develops. --JohnBeckett 11:48, 4 June 2008 (UTC)

---

Return to previous indent

Keep. I invited the author Arnar to explain the issue mentioned, and I intend to consider the resulting comments in the tip. We need to do something with those comments. --JohnBeckett 00:44, 2 June 2008 (UTC)

---

Twitter

See the tips linking to external sites discussion above.

---

This is an understandable position. I agree, that in general it is better if a tip is self-contained, but to follow that as a hard and fast rule all the way then the Vim wiki must also host downloads or reject any tips that require installing external tools. I think that the case for Twit is a different than someone creating an article that does little more than say "Check out the cool info I found on this site here." That clearly doesn't add much. On the other hand, I'm not sure how you would make a formal rule to distinguish the two. It seems like you have to judge on a case-by-case basis and decide which ones are appropriate and add to the Vim Wiki and which ones are noise.

The Twitter tip is not very elaborate to be sure But I think it is philosophically valid for the Vim Wiki. Some tips are valid yet do little more than make you aware of external tools and how they can be used in Vim. And if you are going to describe an external tool then surely you want to provide a link where the tool can be found and downloaded? In the case of the Twitter tip, the external link does little more than bring you to a download page. Otherwise, I'm not sure how you would handle this case within the Vim Wiki.

--Noahspurrier 21:34, 27 May 2008 (UTC)

---

I want to keep this tip, but IMHO it should first be enhanced. I totally agree that this tip is more than a "check out the cool..." post. Also, the external link leads to a quality site.

However, it would not be helpful to have lots of tips that rely on an external link for their content, so I want to have a reason to keep this tip, while deleting others with less value. Or, perhaps Noah (the author) would be happy if a brief summary and the link were placed on an Announcements/Information page, as outlined earlier.

I suggest that the tip should start with an outline of the fact that Vim can interact with external apps, and how this tip illustrates that. Give a brief outline of what is involved so a reader does not have to download and examine a script to work out the concepts.

The tip needs to say what Twitter is: each tip should start by briefly explaining what it actually does, and why you might want it. We should (IMHO) also aim to have each tip provide some technical content, for example, by outlining the associated concepts and implementation issues. Otherwise, our tips would be just a poor substitute for Google. --JohnBeckett 00:44, 2 June 2008 (UTC)

---

Use eval to create dynamic templates

Keep. If we were to merge this info with the other template tips, the result would be too complex. --JohnBeckett 00:44, 2 June 2008 (UTC)

---

Keep -- even if I don't see the point in yet another template expander plugin, and if I've concluded that this approach doesn't scale very well. I've added a comment next to Fritzophrenic's one in the comments section of the tip.

I don't see how it could be easily merged. The only evolution I can think of consists in making this tip as the first part of a not-exactly-tutorial on how a templates expander plugin is designed and written: e.g. 1- the expander engine, 2- triggering expansion: auto-commands, mappings, commands and menus, 3-fetching the templates-files from a 'rtp'-like directory list, 4- all the little extras (i18n, folding, automated-indentation, placeholders).

--Luc Hermitte 12:21, 4 June 2008 (UTC)

---

While you're fundamentally correct, I rather like Fritzophrenic's approach of making a small yet working example, with explanations. I prefer to get by with very few plugins, mainly because I have simple requirements, and this kind of tip allows my kind of user to learn something while doing probably all that is needed for simple cases. So if your proposed tutorial were created, I would suggest doing it in yet another tip to avoid making this one overly complex. --JohnBeckett 01:51, 5 June 2008 (UTC)

Vim setup to edit MoinMoin wiki files

Keep. Probably merge my comments into the tip, replacing the original script. Needs a little more work on explaining exactly where to put all the relevant bits and pieces (I'm not entirely happy with my personal setup which, while working for me, is not quite "correct"). --JohnBeckett 00:44, 2 June 2008 (UTC)

---

VimBlock - Numblock mode for Vim

Keep, I suppose, although should rename. I think the general concept is useful and interesting, although I'm not sure why you would want to remap letters to digits. A couple of things should be cleaned up, like that <C-I> is tab, and some explanation of the key that maps to '0'. --JohnBeckett 00:44, 2 June 2008 (UTC)

---

I don't see the point of this particular example as well. However, I often use a similar technique in scratch buffers. There, several usual keys are locally (<buffer>) hijacked. The technique presented is likely the starting point to implement a feature present in emacs' yasnippet: what the user types is updated in real time in several place(holder)s of the current buffer. BTW, I'd have used inoremap instead of imap. --Luc Hermitte 12:33, 4 June 2008 (UTC)

---

---