Vim Tips Wiki
Register
(Change <tt> to <code>, perhaps also minor tweak.)
 
(11 intermediate revisions by 4 users not shown)
Line 2: Line 2:
 
<big>'''New tips July 2009'''</big>
 
<big>'''New tips July 2009'''</big>
   
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.<br />
 
<!-- (When discussion finished, delete above and remove begin/end of this comment)
 
 
'''This page is an archive listing tips created in July 2009. Please do not edit this page because discussion has finished. If you have any comments, edit the appropriate tip page.'''
 
'''This page is an archive listing tips created in July 2009. 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 [http://lists.wikia.com/mailman/listinfo/vim-l mailing list].
 
Alternatively, comments can be posted on the [http://lists.wikia.com/mailman/listinfo/vim-l mailing list].
   
Line 20: Line 12:
 
|-
 
|-
 
| [[Change gvim colorscheme when focus changes]]
 
| [[Change gvim colorscheme when focus changes]]
|align="center"| -
+
|align="center"| Merged to [[VimTip231]]
 
|-
 
|-
 
| [[Example vimrc]]
 
| [[Example vimrc]]
|align="center"| -
+
|align="center"| Keep
 
|-
 
|-
 
| [[Simple class tree browser]]
 
| [[Simple class tree browser]]
|align="center"| -
+
|align="center"| Flag for deletion if not fixed by October 1
 
|}
 
|}
 
'''Please add your comment (sign with <tt><nowiki>~~~~</nowiki></tt>) below the appropriate heading. Use&nbsp;<tt><nowiki>----</nowiki></tt>&nbsp;between&nbsp;comments.'''
 
   
 
==General comments (not for a specific tip)==
 
==General comments (not for a specific tip)==
Line 35: Line 25:
 
==[[Change gvim colorscheme when focus changes]]==
 
==[[Change gvim colorscheme when focus changes]]==
 
Clever idea, and not complex at all. The content is accessible enough that any user can fix the concerns raised in the comments. Keep. --[[User:Fritzophrenic|Fritzophrenic]] 23:10, 7 August 2009 (UTC)
 
Clever idea, and not complex at all. The content is accessible enough that any user can fix the concerns raised in the comments. Keep. --[[User:Fritzophrenic|Fritzophrenic]] 23:10, 7 August 2009 (UTC)
  +
:Interesting. I would far prefer such a short idea to be included somewhere else, and I will see if I can find a good location. Merging everything runs the risk of giving impenetrable mega tips, but leaving snippets in isolated tips means no one will find them. [[User:JohnBeckett|JohnBeckett]] 11:43, September 5, 2009 (UTC)
  +
New idea: I have merged the text from this proposed tip and from [[VimTip1378]] to [[VimTip231]]. Each of the three tips was very short and cover essentially the same idea: change the color scheme to alert you in some way. I think it makes more sense to have them in one tip, and is more maintainable. See my comments in 231: I need ideas for what to call the combined tip (and I want to keep all the current titles as redirects). I'm not yet committed (I only put the combined text in 231 to see how it looks, and have not yet done anything to the other two tips). What do you think? [[User:JohnBeckett|JohnBeckett]] 07:59, September 22, 2009 (UTC)
  +
:I like this! Your suggested new title (Change the color scheme to show where you are) is decent. Any more descriptive and it could easily too long. I was toying with something like "Change colorscheme to aid multi-file editing" if you want other suggestions. --[[User:Fritzophrenic|Fritzophrenic]] 15:18, September 22, 2009 (UTC)
  +
::Me too. I agree that your proposed title is better than the current one. See my comment on the merged tip. --[[User:Tonymec|Tonymec]] 15:59, September 22, 2009 (UTC)
  +
:::Thanks for feedback. I have cleaned 231 and removed the comments (still visible in the history of 231). [[User:JohnBeckett|JohnBeckett]] 01:50, September 23, 2009 (UTC)
   
 
==[[Example vimrc]]==
 
==[[Example vimrc]]==
Line 41: Line 36:
   
 
::For reference, that discussion is at [[User:Tonymec/Sandbox/Example vimrc (Comments)]]. It is '''NOT YET READY''' for the main part of this wiki, it includes some harsh language that will quite probably have to be edited out before getting out of my Sandbox, and I haven't even reached the end of the [[Example vimrc]] yet. But keeping this in mind, comments (like the one just added by [[User:Fritzophrenic|Fritzophrenic]]) are welcome. --[[User:Tonymec|Tonymec]] 19:00, 8 August 2009 (UTC)
 
::For reference, that discussion is at [[User:Tonymec/Sandbox/Example vimrc (Comments)]]. It is '''NOT YET READY''' for the main part of this wiki, it includes some harsh language that will quite probably have to be edited out before getting out of my Sandbox, and I haven't even reached the end of the [[Example vimrc]] yet. But keeping this in mind, comments (like the one just added by [[User:Fritzophrenic|Fritzophrenic]]) are welcome. --[[User:Tonymec|Tonymec]] 19:00, 8 August 2009 (UTC)
:::Just for the record, I'd like to add that all advanced users in #vim use and recommend <tt>'hidden'</tt>. We believe it's one of the most powerful options Vim has, since it allows for quick buffer navigation - the essence of efficient Vim editing - without being forced to save. <tt>'autowriteall'</tt>, on the other hand, does something that the user might not want. There is nothing ''unsafe'' about <tt>'hidden'</tt>, unless you have set <tt>'noswap'</tt>, which you should definitely not do as a newbie, if ever. <tt>'confirm'</tt> and <tt>'hidden'</tt> do not clash in any way; they work very well together. That being said, I (we) will have nothing against clarifications and comments. ([[User:Spiiph|Spiiph]] 22:15, 8 August 2009 (UTC))
+
:::Just for the record, I'd like to add that all advanced users in #vim use and recommend <code>'hidden'</code>. We believe it's one of the most powerful options Vim has, since it allows for quick buffer navigation - the essence of efficient Vim editing - without being forced to save. <code>'autowriteall'</code>, on the other hand, does something that the user might not want. There is nothing ''unsafe'' about <code>'hidden'</code>, unless you have set <code>'noswap'</code>, which you should definitely not do as a newbie, if ever. <code>'confirm'</code> and <code>'hidden'</code> do not clash in any way; they work very well together. That being said, I (we) will have nothing against clarifications and comments. ([[User:Spiiph|Spiiph]] 22:15, 8 August 2009 (UTC))
  +
::::Well, the most vocal of the advanced users, anyway :-). I'm sure there are some that just keep quiet about such things. As for the option itself, if I worked more by switching buffers rather than just leaving everything I'm working open in various windows or tab pages, I almost certainly WOULD use 'hidden'. But my work style is to keep almost everything visible all the time, and for that 'hidden' just isn't that useful. I like the idea of having 'hidden' in the example .vimrc, I just think we need to be clear that there are alternatives and it is VERY much a matter of preference. --[[User:Fritzophrenic|Fritzophrenic]] 00:30, 9 August 2009 (UTC)
  +
:::::Fair enough. The main point is that this is an important options for users to know about. I believe that this should be how Vim works by default, and that if you use a different work flow (like you), the user should know enough to be able to find and disable it. ([[User:Spiiph|Spiiph]] 11:18, 9 August 2009 (UTC))
  +
  +
::::::Of <code>'hidden' 'confirm'</code> and <code>'autowriteall'</code>, no more than one of which should IMHO be on by default (unlike in the [[Example vimrc]] which sets both <code>'hidden'</code> and <code>'confirm'</code>), I believe that a quite valid point could be made in favour of <code>'confirm'</code>, which IMHO is least surprising to beginners. At least (IMHO) everyone ought to know about its existence and how to turn it on or off. For more advanced users, either <code>'hidden'</code> or <code>'autowriteall'</code> could become '''the user's choice,''' and IMHO everyone (except maybe rank beginners) should know about both of them. --[[User:Tonymec|Tonymec]] 13:01, 9 August 2009 (UTC)
  +
::::::P.S. About <code>'autowriteall'</code> possibly doing what the user wouldn't want: When I first started using PCs some 25 years ago on Dos 2.x, I was trained to save everything at least once every quarter-hour and I used an editor which would save any changes in the current file even when going to the other split-window. I don't believe this "early training" was ill-founded and I'm not going to try to unlearn it; so before I start making, in a file, changes which I think I mightn't want to save, I first create a scratch copy of the file with [http://vimdoc.sourceforge.net/cgi-bin/help?tag=%3Asaveas :saveas]. --[[User:Tonymec|Tonymec]] 13:17, 9 August 2009 (UTC)
  +
:::::::Again, <code>'confirm'</code> works perfectly fine with <code>'hidden'</code>. They are perfectly compatible, make a good match, and doesn't add any "surprising" behaviour in addition to what <code>'hidden'</code> does. The only thing that changes with <code>'hidden'</code> is that you won't get a confirmation when a buffer is about to be abandoned; only when it is to be unloaded and there are unsaved changes. I also believe that the reason you mention for using <code>'autowrite'</code> is rather backwards. There's no real point in saving that often when you have swap files, unless you don't trust them, but that's my opinion. ([[User:Spiiph|Spiiph]] 14:41, 9 August 2009 (UTC))
   
 
==[[Simple class tree browser]]==
 
==[[Simple class tree browser]]==
 
Needs work before we can keep it. Wait a couple months and if our concerns haven't been met, mark it for deletion and delete after a normal wait period. Until then it's just another unexplained external script. --[[User:Fritzophrenic|Fritzophrenic]] 23:10, 7 August 2009 (UTC)
 
Needs work before we can keep it. Wait a couple months and if our concerns haven't been met, mark it for deletion and delete after a normal wait period. Until then it's just another unexplained external script. --[[User:Fritzophrenic|Fritzophrenic]] 23:10, 7 August 2009 (UTC)
  +
:As if we don't have enough troubles! The script is quite good quality, and reading it makes me think that the tip should be kept as potentially useful for some reader. But it is six weeks since some very reasonable questions were raised in the tip comments, and I would prefer to spend my time fixing the existing tips rather than fixing this one. In the past, it was to standard to have tips where the reader has to spend ten minutes working out wtf is going on, but I don't think we should accept that unless a new tip has a really clever trick. Therefore, I am going to take Fritzophrenic's suggestion and will flag the tip for deletion if no one gets around to fixing it before October. [[User:JohnBeckett|JohnBeckett]] 11:43, September 5, 2009 (UTC)
   
 
----
 
----

Latest revision as of 08:36, 15 July 2012

New tips July 2009

This page is an archive listing tips created in July 2009. 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 Current consensus
Change gvim colorscheme when focus changes Merged to VimTip231
Example vimrc Keep
Simple class tree browser Flag for deletion if not fixed by October 1

General comments (not for a specific tip)[]

Change gvim colorscheme when focus changes[]

Clever idea, and not complex at all. The content is accessible enough that any user can fix the concerns raised in the comments. Keep. --Fritzophrenic 23:10, 7 August 2009 (UTC)

Interesting. I would far prefer such a short idea to be included somewhere else, and I will see if I can find a good location. Merging everything runs the risk of giving impenetrable mega tips, but leaving snippets in isolated tips means no one will find them. JohnBeckett 11:43, September 5, 2009 (UTC)

New idea: I have merged the text from this proposed tip and from VimTip1378 to VimTip231. Each of the three tips was very short and cover essentially the same idea: change the color scheme to alert you in some way. I think it makes more sense to have them in one tip, and is more maintainable. See my comments in 231: I need ideas for what to call the combined tip (and I want to keep all the current titles as redirects). I'm not yet committed (I only put the combined text in 231 to see how it looks, and have not yet done anything to the other two tips). What do you think? JohnBeckett 07:59, September 22, 2009 (UTC)

I like this! Your suggested new title (Change the color scheme to show where you are) is decent. Any more descriptive and it could easily too long. I was toying with something like "Change colorscheme to aid multi-file editing" if you want other suggestions. --Fritzophrenic 15:18, September 22, 2009 (UTC)
Me too. I agree that your proposed title is better than the current one. See my comment on the merged tip. --Tonymec 15:59, September 22, 2009 (UTC)
Thanks for feedback. I have cleaned 231 and removed the comments (still visible in the history of 231). JohnBeckett 01:50, September 23, 2009 (UTC)

Example vimrc[]

Keep We have previously agreed that dumps of vimrc files are not helpful, although any user is welcome to make a user subpage with their vimrc if they think it would be helpful to others. If we get a few of these, we might make a central list to link to them. However, I think this example is of a different nature from the previous vimrc dump that we deleted. This version is simple and aimed to be helpful for new users, and has explanations. It would be unhelpful to over complicate it with a bunch of "OTOH you might use this alternative...", so whereas a few more things might be added, I prefer the simple way it is now. JohnBeckett 12:51, 6 August 2009 (UTC)

I agree. We should eventually merge in some of the discussion that Tony M is working on, so that readers get the pros and cons of some of the settings (particularly the 'hidden' and 'confirm' options). --Fritzophrenic 23:10, 7 August 2009 (UTC)
For reference, that discussion is at User:Tonymec/Sandbox/Example vimrc (Comments). It is NOT YET READY for the main part of this wiki, it includes some harsh language that will quite probably have to be edited out before getting out of my Sandbox, and I haven't even reached the end of the Example vimrc yet. But keeping this in mind, comments (like the one just added by Fritzophrenic) are welcome. --Tonymec 19:00, 8 August 2009 (UTC)
Just for the record, I'd like to add that all advanced users in #vim use and recommend 'hidden'. We believe it's one of the most powerful options Vim has, since it allows for quick buffer navigation - the essence of efficient Vim editing - without being forced to save. 'autowriteall', on the other hand, does something that the user might not want. There is nothing unsafe about 'hidden', unless you have set 'noswap', which you should definitely not do as a newbie, if ever. 'confirm' and 'hidden' do not clash in any way; they work very well together. That being said, I (we) will have nothing against clarifications and comments. (Spiiph 22:15, 8 August 2009 (UTC))
Well, the most vocal of the advanced users, anyway :-). I'm sure there are some that just keep quiet about such things. As for the option itself, if I worked more by switching buffers rather than just leaving everything I'm working open in various windows or tab pages, I almost certainly WOULD use 'hidden'. But my work style is to keep almost everything visible all the time, and for that 'hidden' just isn't that useful. I like the idea of having 'hidden' in the example .vimrc, I just think we need to be clear that there are alternatives and it is VERY much a matter of preference. --Fritzophrenic 00:30, 9 August 2009 (UTC)
Fair enough. The main point is that this is an important options for users to know about. I believe that this should be how Vim works by default, and that if you use a different work flow (like you), the user should know enough to be able to find and disable it. (Spiiph 11:18, 9 August 2009 (UTC))
Of 'hidden' 'confirm' and 'autowriteall', no more than one of which should IMHO be on by default (unlike in the Example vimrc which sets both 'hidden' and 'confirm'), I believe that a quite valid point could be made in favour of 'confirm', which IMHO is least surprising to beginners. At least (IMHO) everyone ought to know about its existence and how to turn it on or off. For more advanced users, either 'hidden' or 'autowriteall' could become the user's choice, and IMHO everyone (except maybe rank beginners) should know about both of them. --Tonymec 13:01, 9 August 2009 (UTC)
P.S. About 'autowriteall' possibly doing what the user wouldn't want: When I first started using PCs some 25 years ago on Dos 2.x, I was trained to save everything at least once every quarter-hour and I used an editor which would save any changes in the current file even when going to the other split-window. I don't believe this "early training" was ill-founded and I'm not going to try to unlearn it; so before I start making, in a file, changes which I think I mightn't want to save, I first create a scratch copy of the file with :saveas. --Tonymec 13:17, 9 August 2009 (UTC)
Again, 'confirm' works perfectly fine with 'hidden'. They are perfectly compatible, make a good match, and doesn't add any "surprising" behaviour in addition to what 'hidden' does. The only thing that changes with 'hidden' is that you won't get a confirmation when a buffer is about to be abandoned; only when it is to be unloaded and there are unsaved changes. I also believe that the reason you mention for using 'autowrite' is rather backwards. There's no real point in saving that often when you have swap files, unless you don't trust them, but that's my opinion. (Spiiph 14:41, 9 August 2009 (UTC))

Simple class tree browser[]

Needs work before we can keep it. Wait a couple months and if our concerns haven't been met, mark it for deletion and delete after a normal wait period. Until then it's just another unexplained external script. --Fritzophrenic 23:10, 7 August 2009 (UTC)

As if we don't have enough troubles! The script is quite good quality, and reading it makes me think that the tip should be kept as potentially useful for some reader. But it is six weeks since some very reasonable questions were raised in the tip comments, and I would prefer to spend my time fixing the existing tips rather than fixing this one. In the past, it was to standard to have tips where the reader has to spend ten minutes working out wtf is going on, but I don't think we should accept that unless a new tip has a really clever trick. Therefore, I am going to take Fritzophrenic's suggestion and will flag the tip for deletion if no one gets around to fixing it before October. JohnBeckett 11:43, September 5, 2009 (UTC)