FANDOM

Willkommen, bienvenue, welcome, welkomEdit

Welcome to the Vim Tips wiki! We hope you can help improve the articles by fixing typos, adding comments (at the bottom of each tip page), rewriting tips, joining in discussions, or making other improvements.

Be sure to visit the community portal for information about our site, with links to how to pages.

Keep an eye on recent changes to check progress.

Our policy guidelines may be useful. We'd like you to join the very low-volume mailing list.

Enjoy!


Tip 1166 Sort linesEdit

Hi Sirrobert. Thanks for developing Sort lines. Now that you're one of the family, please feel free to clean up the comments as well, if you feel it to be appropriate. We like to put temporary discussions in the Comments section on the tip page, but when matters are attended to, we delete the notes (but we always keep the ==Comments== heading). We just ask that people only delete material that really has been fixed (if in doubt, leave it). The old notes are always available in the history of the page, if we need to review deleted text. Be sure to ask (you could reply here) if there's anything you would like to discuss. --JohnBeckett 08:43, 19 December 2008 (UTC)


Thanks, John. I'll be sure to do just that in the future! I've been looking for a resource like this for a while -- thanks for making it! (Sirrobert 14:09, 19 December 2008 (UTC))

Ranges and TransclusionEdit

You're very familiar with wiki ways. It would never occur to me to provide an explanation of transclusion here since very few contributors need that information, and generally I would encourage people to concentrate on the Vim Tips side of the wiki, rather than think about Mediawiki material (particularly since there is a tremendous amount of Vim stuff we should attend to).

Your new Ranges page is a great idea. There are a few other cases where we should put key Vim information like this in one article, then link to it as a reference from other tips.

However, while it may grow on me, at the moment I don't think that including a table with :s examples in Sort lines is helpful. I think it would be better to restore a couple of examples using :sort with a range, then simply link to the Ranges tip for more information. For example, a lot of Vim users would have no idea that a group of contiguous lines could be sorted by selecting the lines with vip then entering :sort. A very simple statement of that, and maybe a little more, should appear because it wouldn't be easy to work that out from reading a generic article on Ranges. I would not like that "ranges cheat sheet" to appear in more than a small number of tips.

We don't have to agree on everything, but I think that the most helpful tips start with simple information, then show details and complex cases later (if necessary). So, I would prefer the Ranges tip to have some simple cases right at the top (with mnemonics and range errors and so on, later).

Also, all our pages use the style of omitting redundant spaces in wikitext, and we use <tt>command</tt> rather than <code>command</code>. Of course, the code tag is technically correct, and if you prefer code, that's fine by me. However, if you edit other tips, I would recommend keeping the tt tags.

Examples of "omitting redundant spaces" would be ==Heading== and *Bullet point.. Again, feel free to put whatever you like on useful pages that you create, but I suggest being consistent with our style on existing pages.

Why put that line about Vim 7.2 and RedHat at the top of the Ranges page? I haven't yet had time to study the page, but I wouldn't expect to find anything where you needed to specify the exact Vim version and operating system. --JohnBeckett 04:22, 20 December 2008 (UTC)


Thanks for the input, John.

I'll check out the Project:todo page -- I hadn't seen it before.

As for the range table and its inclusion in Sort lines or other pages; I'm completely for any changes to my contributions and the nixing of any of my ideas. Feel free to change anything I ever do in the wiki without the need to explain to (or even alert) me -- I probably won't notice, and am always happy to defer to someone else's expertise anyway.

Thanks for the input regarding the tt vs. code tags. I'm happy to conform 100% to the community's conventions in every way, but it'll take me a bit to become aware of them all and to habituate myself! Thanks for your patience =) I'll start adopting the space-minimization style and tt tags immediately.

Regarding the inclusion of OS and version info I looked for a page about the proper structure of a page on the wiki but didn't find one, so I went to some random tip page and tried to emulate what was there. I don't remember which it was, but it had version and OS info at the top, so I just did the same thing. Is there a page that tells "best practices" for creating tips or other pages in the wiki? Also, how does one acquire a tip number for a new tip?

About the format of tip pages, your suggestions make good sense to me. I tend to address things philosophically rather than pragmatically (perhaps because my degree is in philosophy and literature =). I view all of my wiki contributions as works in progress, and am very eager for anyone to deform them as they will. We're like a plague of beneficial locusts, each contributing a tiny positive thread to a tapestry of construction =) Any changes you'd like in the Ranges page -- or anywhere else -- are entirely welcome.

Thanks! --Sir Robert Burbridge 17:12, 22 December 2008 (UTC)


Hi, Sirrobert! It's good to see someone new who seems excited about editing the wiki. As I was discussing with John elsewhere, I really like the idea of transclusion (it's a new concept to me), but the "range cheatsheet" (at least in its current form) doesn't seem to be the best use of it. I do like the new range page (though obviously, like almost everything else on this wiki, it needs a little work).

Regarding tip numbers and info in the header of the tip: I like that you tried to match other tips, but here's how all that works:

  1. Someone creates a new tip
  2. John periodically looks for new tips and adds a "tip proposed" template to it, which links to a new tips page where it will be discussed later (see below).
  3. At the end of every month, we review all the tips that have been added on one of the new tips lists. We decide which ones to keep, which ones to merge to an existing tip, and which ones to just get rid of (for various reasons...though this option is used rarely).
  4. After the fate of each tip is decided, someone (usually John) adds the tip header to the new tips that we decide to keep, giving them a tip number in the process.

We decided to do it this way primarily in order to combat the problem of duplicate tips, but also because we are still pruning some old tips that just aren't useful anymore (or never were). In general, we accept most tips, but tips that are just external links, and tips that are just a summary of some plugin content, usually are removed.

Good job "being bold" (as we say) and just jumping right in to editing...but, now you have a little better idea how things (currently) work around here.

--Fritzophrenic 17:25, 22 December 2008 (UTC)


Thanks very much for your positive reaction to my comments. I must say that quite a number of Vim users seem to be good people! I will probably add more comments. For brevity, I might sound a bit didactic, but I'm really just stating my opinion and am very happy to discuss other points of view.

Re the Project:todo page: A couple of months ago (before the advertisements), the default skin here was monobook. That had a "todo" link. I intend editing the sidebar for the current skin one day.

Are you sure you want your signature to display your email address? Clearly you know what you are doing, but we've deleted all addresses from here to minimise spam (there were a lot of addresses in the older tips). --JohnBeckett 04:12, 23 December 2008 (UTC)

New tipsEdit

Fritzophrenic has explained about new tips. Some extra points: I use a lot of scripts and a bot to process new tips. Also, we are several months behind our schedule. It would be great if you wanted to offer some opinions, starting at July new tips. We try to be polite (and not offend authors when we don't keep their tips), but I would urge participants to be realistic: It's probably not much help saying that a proposed new tip would be worthwhile if a bunch of fixing was done. The question is, given that we have an infinite amount of work and a small number of participants, is a new tip going to be helpful? If not, it should be deleted IMHO.

With some exceptions, we usually avoid saying "delete" when discussing proposed new tips. Instead, we "merge" useful content into some other tip (sometimes a vanishingly small amount of content). It's nicer for an author if their tip is merged rather than deleted.

Also, particularly since we are several months behind, if you do add some comments, please keep them brief. Essentially, I just want the bottom line: should a tip be kept or merged? Bear in mind that keeping a tip means we have to fix it -- given the hundreds of broken old tips that we have, I really don't want to add new broken tips. I don't want to take action on a tip without the agreement of at least one other editor. --JohnBeckett 04:12, 23 December 2008 (UTC)

Merging tipsEdit

Our merge guidelines have a quick overview of how we combine tips. Our documentation is brief, mainly because there is a limit on how much people can read or comprehend. We will certainly never have the "manual of style" or other policy documents of Wikipedia (we're interested in Vim, not policies). Therefore, if you don't mind, I'd like to leave notes like this from time to time.

Here is some background to explain the basis for our merging procedure. Consider Use GVim as an external editor for applications which you intended to combine VimTip805 and VimTip809. If we were to pursue that plan, we would have to delete tips 805 and 809. However, there are a lot of people who have browsed the old vim.org tips site (or this site), and who may have notes or links that refer to these tips. It's very possible that someone will arrive here looking for tip 805 by its tip number or title. Therefore, we keep tip 805 and (if wanted) merge 809 into it. Later, I would change 809 so its tip number and title redirect to 805.

Keeping 805 (and merging related tips into it) has these benefits:

  • With no extra work, we keep an old tip number (one less redirect, and less confusion).
  • We don't need a new tip number for a new page.
  • We acknowledge the original author. Sometimes I remove the author when nothing remains of the original tip (even then I might keep the author if they were the first to come up with a good idea). That's why we merge high-numbered tips to lower numbered tips (the first author is retained, even if their tip was a mess). Exceptions may sometimes be warranted (e.g. maybe merge low number to high if the first tip was a disaster).
  • The history of the old tip remains for anyone interested.

Please note that an over-riding principle is that each tip should be reasonably simple and short. Sure, there will be lots of complex and long exceptions, but the vast majority of tips should be comprehensible to general Vim users, and short. In particular, while I haven't studied tips 805 and 809, I seriously doubt whether there is any benefit from merging them. It's just too complex to have one tip that deals with both Windows and Linux procedures (unless you can put all the platform-dependent material in half a screen).

Also, consider the future of 805 and 809. It's likely that people will have extra material to add to each (example), and there are probably other tips with similar content that might be merged in. That is, these particular tips are bound to grow, which is another reason why merging them is not going to work.

Finally, our procedure of flagging tips that are candidates-for-merging with the Duplicate template alerts other editors, who may want to add an opinion before any significant merging occurs (however, don't worry about that; if I arrive tomorrow and find a bunch of useful merging done, I'm not going to complain). --JohnBeckett 04:12, 23 December 2008 (UTC)

Our conventionsEdit

We have the convention of spelling Vim's names as "Vim" and "gvim" (see our Quick reference). Of course we say "vim" and "gvim" in a command ("vim -d file1 file2") or a file name ("vim.exe" on Windows). Exception: At the start of sentence, say "Gvim" (however, it's often best to just avoid using "gvim" except when really needed).

The basis for our convention is Vim's documentation. That documentation has evolved over many years, but "Vim" is now definitely the preferred generic name, and "gvim" is frequently used (there are only a couple of "GVim", a sprinkling of "gVim", and a few "Gvim").

Some other conventions:

  • "FireFox" should be "Firefox".
  • "windows program" should be "Windows program".
  • There is no ==Overview== heading at the start of a tip (Wikipedia articles don't have an initial heading either).

Most of our tips are still somewhat broken as far as presentation is concerned. Two reasons for this are:

  • Good content is a lot more worthwhile than good presentation (particularly for most Vim users, many of whom think that nothing beats monospaced light-on-dark text).
  • Lots of our tips should probably be merged or deleted. If we spent too much time fixing the presentation we would lose sight of that (and we'd waste a lot of time by polishing material that should be deleted).

Two good tips are The super star and Working with CSV files. I mention the CSV tip because it is well presented, but it's not an ideal tip because it's too long and isn't much more than a recipe (the best tips teach the reader something).

Finally, please don't let my verbosity put you off. Welcome to our wiki! --JohnBeckett 04:12, 23 December 2008 (UTC)


That all looks good to me -- I'll begin adopting it immediately. Don't worry, even the most rotund politician would be hard-pressed to put me of by mere verbosity ;)

--Sir Robert Burbridge 21:26, 23 December 2008 (UTC)

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