Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
New tips March 2010
This page is an archive listing tips created in March 2010. Please do not edit this page because discussion has finished. If you have any comments, edit the appropriate tip page.
|Proposed new tip||Current consensus|
|Build Python-enabled Vim on Windows with MinGW||Kept as VimTip1650|
|Last position jump improved for Easy Vim||Redirect to Script:3059|
|Project specific settings||Kept as VimTip1649|
- Build Vim in Windows with Cygwin (MinGW is not very different)
- Compile a separate copy of Vim for Python coding (dodgy)
- Where to download Vim (including W32 binaries with Python etc.)
Merge (if deemed useful) otherwise delete? — Tonymec 19:42, March 30, 2010 (UTC)
I'm not sure about this at the moment. It has good content which needs to be kept, although like all the build tips it needs work. Re the point of the tip, I'm sure that it would be better and easy to find a Vim without Cream install to support the wanted version of Python, but proper info on building your own Vim needs to be on the wiki eventually. I have put all the "building Vim" tips I know of at Where to download Vim#Comments. I'll think some more later. JohnBeckett 10:32, May 20, 2010 (UTC)
I think for now, we should keep it. We should put all the "building" tips in Category:Building Vim and eventually create "building on Unix" and "building on Windows" tips which we can potentially merge to. I've seen Tony's pages, and while they are an excellent resource which we should link to, they do make things look (at first glance anyway) to be much more complicated than they actually are. I found Version independent installation of Vim on Windows today, which was really the final step I was missing to easily build my own Vim (that and the :help entries it relates to). Even this tip makes things complicated with a custom batch file to set options (without much explanation) but it's good enough for now.
--Fritzophrenic 20:32, July 10, 2010 (UTC)
I have to say, after using this tip to very quickly and without wading through a lot of info figure out how to build a python-enabled Vim to try out the Gundo plugin, I think we should definitely keep this tip by itself. I like the idea of a "Building" category that collects a bunch of build-related tips like this one, that may solve a very specific build problem for people that already know the basics. --Fritzophrenic 04:18, October 22, 2010 (UTC)
I agree this should be kept. This is reportedly resolving a deficiency with the current Vim distribution, not just adding a new feature.
I do think we need to somehow distinguish it from a "normal" tip, and provide some call for somebody to take over the maintenence, either on vim.org or as an official plugin. Maybe a new template is in order for such things? --Fritzophrenic 14:46, May 20, 2010 (UTC)
As for the email, you should be able to un-follow the page. But we would certainly like to remove the page. Is there a script page on vim.org which we can redirect to instead of deleting it outright? Some people may have in bookmarked/linked. --Fritzophrenic 02:34, March 25, 2011 (UTC)
Let's finish this! The script is unmaintained, unexplained, and not the kind of page wanted as a tip. If if fixes problems in a file distributed with Vim, it should be included in the distribution. There has been no reply to Fritzophrenic's above question, and the author requests deletion, so let's just delete it. While deleting stuff is a shame, and breaking incoming links very bad, those of us who are maintaining the wiki need to face the reality that we are overwhelmed and need to move forward. Alternatively, if someone can fix the page in some way very soon, I would be happy with that. As a compromise, I would also be happy to replace the page with a redirect to this discussion. JohnBeckett 05:15, April 16, 2011 (UTC)
- How about a redirect to Script:3227, which is the script Broofa recommends? We could add a "similar plugins" section to the script page with the same list as on the tip page. --Fritzophrenic 15:02, April 18, 2011 (UTC)
- Done. JohnBeckett 05:07, April 19, 2011 (UTC)
I have no idea what this is about but propose keeping the tip in view of its author. Perhaps Anwo will notice my confusion and add a short introduction saying why it's needed: what goes wrong if you do not use this tip? is the cursor slightly incorrectly restored? does that matter? does Vim crash? or what? JohnBeckett 10:32, May 20, 2010 (UTC)
I imagine (I have not tried it) that Vim will simply not position the cursor. In general, jumping in normal mode to a position that does not exists just beeps; the cursor remains in the same place. I'm guessing that the default "restore position" autocmd will simply do nothing in Easy Mode, so that the file always opens with the cursor at the beginning.
I may of course be very wrong, but I think we should keep the tip (and probably remove comments about not using vim in "Easy mode", since people just want to know "how do I use Easy mode Vim?" without a lecture). --Fritzophrenic 20:48, July 10, 2010 (UTC)
- A comment in the tip by the author shows that the tip is now at script#3059. I propose replacing this tip with a redirect to Script:3059, and put some of the content (the image and a tiny description) on the Script:3059 page. I would remove the script and installation notes. JohnBeckett 03:52, February 25, 2011 (UTC)
- I have marked the "consensus" above to redirect the page as in my above suggestion, and have put a comment on the tip in case the author is following that page and would like to comment before action is taken. Fritzophrenic: any thoughts? JohnBeckett 05:15, April 16, 2011 (UTC)
Agree. Probably make sure there's a See also note in each. --Fritzophrenic 14:47, May 20, 2010 (UTC)
Other solutions should be evoked in the tip page. I'm thinking about the plugins local_vimrc (there exists 3, may be 4 now, different implementations of the concept on SF), or plugin. They address exactly the same concern: having project-specific settings (actually, project does much more).