This is an archive – please don't edit.
- I've marked Restoring_indent_after_typing_hash for deletion. 'smartindent' should (in general) be avoided like the plague, and it doesn't seem to be a very good tip anyway. (Spiiph 14:01, 29 July 2009 (UTC))
- I disagree with this deletion (although I do agree that 'smartindent' isn't smart at all). For now, I'd mark the tip {{dodgy}} instead of {{delete}}. Eventually, we should merge in the comments and recommend NOT using 'smartindent' (and using 'cindent' or filetype indentation instead) before we present the workaround for bad 'smartindent' behavior. But, some people will no doubt ignore our advice about not using 'smartindent', and information about how to work around it is probably useful. --Fritzophrenic 14:22, 29 July 2009 (UTC)
- Fair enough. I guess it might be a good page to catch people using 'smartindent' and give them a slap on the fingers. ;) That the example in the :help 'smartindent' doesn't work in .vimrc is bogus information, though, and we should just copy that text. (Spiiph 15:19, 29 July 2009 (UTC))
- [OT] Why give them a slap on the fingers? I like 'smartindent' much better than I do :filetype indent on — it indents my vim-scripts reasonably nicely and doesn't try to mess with my unsystematic HTML indenting. (I rarely program in C, and when I do I use /* */ comments, and directives with # in column 1 possibly followed by indenting spaces before if, ifdef, define, etc.; in sh-script I don't use # other than in the first column; so I don't have the described problem anyway.) — Tonymec 22:25, 2 August 2009 (UTC)
- Because 'smartindent' adds nothing of value on top of :filetype indent on. It also creates a lot of support questions from users wondering why their #'s keep ending up in the first column in their Ruby or Python files. I can allow that an experienced user might prefer 'smartindent', (even though I don't understand why), but I don't think it should be advocated; ever. Anyway, the "slap on their fingers" was said jokingly; a "don't use this option unless you know what you're doing"-warning might be more suitable. (Spiiph 22:35, 2 August 2009 (UTC))
- 'smartindent' was never meant to add anything of value on top of :filetype indent on — indeed, it is overridden by either 'cindent' or 'indentexpr' (which are the options usually set by filetype-related indenting, except maybe for Lisp), so if you use :filetype indent on, 'smartindent' will probably rarely or never make any difference to you. But :filetype indent on tries to overrule my own way of indenting files (HTML pages for instance) — thinking that it knows how I ought to behave better than I do, so it tries to make what it calls "my own good" in its own way and against my will, something I hate — so I disable it. Then 'smartindent' gives me something useful — something of value instead of :filetype indent on or, if you prefer, on top of :filetype indent off. As for Ruby, I don't know anything about it it, and I dislike Python because it gives syntax meaning to whitespace — the amount of it at the start of a line. I want to be able to restore correct indenting in a program even if some accident (in mail transport, say) removes all start-of-line indenting. — Tonymec 23:05, 2 August 2009 (UTC)
- P.S. I might say that I like smart indenting, but not smartass-indenting, which is what I get when the indenting routine tries to appear smarter than it really is. — Tonymec 23:16, 2 August 2009 (UTC)
- So just because you don't use Ruby, and dislike Python, you recommend using 'smartindent' to users? Regardles of what :help 'indendexpr' says, 'smartindent' interferes with indentation even if 'indentexpr' is set, by placing #'s at the first column. This is why recommending 'smartindent' is a bad idea. (Spiiph 10:17, 3 August 2009 (UTC))
- I don't recommend that everyone use it, but neither do I approve the statement that no one should ever use it, even up to saying (if jocularly) that its users ought to be slapped on the fingers for it. 'smartindent', like anything in Vim, should not be misused but it can (and should) be used with reason, by users with whose style it meshes well, and in particular, I don't believe that one should use both :set smartindent and :filetype indent on globally in the vimrc. When I was a Vim newbie, it took me months to track why Vim was bossily changing the indents in my HTML pages without my say-so, and that the solution was to add :filetype indent off after I source the vimrc_example.vim At least, 'smartindent' is off by default, regardless of whether the example vimrc is being used: You can only have it on if you explicitly set it on. — Tonymec 11:06, 3 August 2009 (UTC)
- There are enough cases of misguided usage that ample warning is justified. Plenty of example .vimrcs on the web sets 'smartindent', and users greedily add it in addition to having filetype indent on. "Of course you want it enabled. It's smart, right? It's in the name!" The majority of users, judging by the sample appearing on Vim_on_Freenode, want filetype indent on and are mightily confused by the behaviour of 'smartindent'. These users might benefit from a slap on their fingers, for enabling an option without understanding it. This is EOD for my part. (Spiiph 12:18, 3 August 2009 (UTC))
- I don't recommend that everyone use it, but neither do I approve the statement that no one should ever use it, even up to saying (if jocularly) that its users ought to be slapped on the fingers for it. 'smartindent', like anything in Vim, should not be misused but it can (and should) be used with reason, by users with whose style it meshes well, and in particular, I don't believe that one should use both :set smartindent and :filetype indent on globally in the vimrc. When I was a Vim newbie, it took me months to track why Vim was bossily changing the indents in my HTML pages without my say-so, and that the solution was to add :filetype indent off after I source the vimrc_example.vim At least, 'smartindent' is off by default, regardless of whether the example vimrc is being used: You can only have it on if you explicitly set it on. — Tonymec 11:06, 3 August 2009 (UTC)
- So just because you don't use Ruby, and dislike Python, you recommend using 'smartindent' to users? Regardles of what :help 'indendexpr' says, 'smartindent' interferes with indentation even if 'indentexpr' is set, by placing #'s at the first column. This is why recommending 'smartindent' is a bad idea. (Spiiph 10:17, 3 August 2009 (UTC))
- Because 'smartindent' adds nothing of value on top of :filetype indent on. It also creates a lot of support questions from users wondering why their #'s keep ending up in the first column in their Ruby or Python files. I can allow that an experienced user might prefer 'smartindent', (even though I don't understand why), but I don't think it should be advocated; ever. Anyway, the "slap on their fingers" was said jokingly; a "don't use this option unless you know what you're doing"-warning might be more suitable. (Spiiph 22:35, 2 August 2009 (UTC))
- [OT] Why give them a slap on the fingers? I like 'smartindent' much better than I do :filetype indent on — it indents my vim-scripts reasonably nicely and doesn't try to mess with my unsystematic HTML indenting. (I rarely program in C, and when I do I use /* */ comments, and directives with # in column 1 possibly followed by indenting spaces before if, ifdef, define, etc.; in sh-script I don't use # other than in the first column; so I don't have the described problem anyway.) — Tonymec 22:25, 2 August 2009 (UTC)
- Fair enough. I guess it might be a good page to catch people using 'smartindent' and give them a slap on the fingers. ;) That the example in the :help 'smartindent' doesn't work in .vimrc is bogus information, though, and we should just copy that text. (Spiiph 15:19, 29 July 2009 (UTC))
- I reviewed the tip in a way I think is beneficial to most users. It is no longer marked for deletion or dodgy. (Spiiph 12:21, 3 August 2009 (UTC))
- I disagree with this deletion (although I do agree that 'smartindent' isn't smart at all). For now, I'd mark the tip {{dodgy}} instead of {{delete}}. Eventually, we should merge in the comments and recommend NOT using 'smartindent' (and using 'cindent' or filetype indentation instead) before we present the workaround for bad 'smartindent' behavior. But, some people will no doubt ignore our advice about not using 'smartindent', and information about how to work around it is probably useful. --Fritzophrenic 14:22, 29 July 2009 (UTC)
- I've marked another tip (Access_Python_Help) for deletion, as a duplicate of Get_help_on_Python_libraries, and I think that no further merging is necessary. Is it okay to remove the {{review}} template after having done so? (Spiiph 21:36, 29 July 2009 (UTC))
- Advice on review/delete/merge
Remove {{review}} if you are confident that the advice in a tip is good and that it should work. Preferably, you would test that the tip does work, but if you are very confident, that is probably enough. A reviewed tip does not need to be perfect (it may have a couple of "todo" or other comments). By removing review you are saying that the tip is not misguided, and is in a fit state to be read (it does not have bad advice, and does not have a lot of comments, particularly conflicting comments).
I also remove review if flagging a tip as merged (it's a bit confusing having "this tip has been merged" and "this tip needs review").
Merge guidelines: We prefer to merge high-numbered tips to the tip with the lowest tip number on the basis that the first tip created has a prior claim, and in an ideal world, the later tips would have been merged into the first tip instead of being created as separate tips. There are exceptions, particularly if the first tip is misguided.
The important point is to not remove useful information. For example, in the case above, one tip creates a temp file then uses :pedit to view that file. The other tip attempts to make a scratch buffer (I think not quite correctly), then reads the standard output from running an external program. We would need to consider whether the second method is worth mentioning as an alternative in the final merged tip. I'm not going to think about that right now – I'm just pointing out the general issue. There is no need to take this advice too far: the perfect is the enemy of the good, and if some incidental info is omitted, that is too bad.
We only delete a tip if it really is unhelpful and we don't have another similar tip. Suppose tip 101 and tip 102 cover roughly the same topic, using different methods. We might decide that 102 is completely superfluous (maybe Vim 7 does not require its hacks, or perhaps 101 has been improved so it's much better than 102). Even if we just want to delete 102, we would still declare that 102 has been merged into 101. When I process it, the title for 102 would become a redirect to the title of 101, and VimTip102 would be replaced with a message saying to see VimTip101. Also, it's much more friendly to the author of a tip to find that their work has been merged rather than deleted.
With the above example, after confirming that all useful info from 102 is in 101, you would put {{merged|101}} at the top of 102 (replacing {{review}} if present).
If I merge information from 102 into 101, I would put an edit summary on the addition to 101 like "merge in from 102 by X", replacing X with the author of 102. That is to give credit. Lately, I have been doing history merges as well, which means that the edit history of 102 becomes merged into the edit history of 101. I'm not sure how often I'll do that, but it is the proper procedure.
One day I'll put this advice somewhere more permanent. JohnBeckett 00:18, 30 July 2009 (UTC)
- Got it. Updating. (Spiiph 08:51, 30 July 2009 (UTC))
- There, I think I managed to get that right. (Spiiph 11:34, 30 July 2009 (UTC))
Hmm, are there instructions or at least information about merging the history as you mention? I do occasionally (very occasionally, I admit) get around to doing some big merges, and it would probably be good if that trick was up my sleeve as well. I assume I have all the privileges needed?
--Fritzophrenic 00:55, 30 July 2009 (UTC)
- I just made two subpages (see my user page for links) with the guidelines I mentioned above, and with history merge info. JohnBeckett 04:26, 30 July 2009 (UTC)
Search Web from within Vim using Firefox and Google[]
If this tip had the least bit of explanation! If it weren't windows-only! If it weren't meant only for a Spanish-localized OS! — Isn't there a standard environment variable which resolves to "C:\Archivos de programa" on Spanish Windows, to "C:\Program Files" on English Windows, and to the local equivalent elsewhere? And by the way, shouldn't the "program name" argument to start need double quotes, especially if it includes spaces in its path? Delete — unless very seriously reworked and expanded — Tonymec 23:06, 20 August 2009 (UTC)
- I agree that VimTip1157 did not have useful content. However, I have copied it to VimTip394 where it will eventually be merged in (with most of the repetitive material probably removed). JohnBeckett 08:20, March 1, 2010 (UTC)
Removal of Change cursor movement keys for Dvorak layout[]
- Archived since no developments since December 2010; have redirected tip 1390 to 1437 JohnBeckett 10:15, April 19, 2011 (UTC)
There is a request to remove Tip 1390 in favor of the "better solution" Tip 1437. I do not believe either solution is ideal for all users, and that they should live in harmony. Personally I am curious if their is a difference from using the Dvorak keymap that comes with Vim. I think each page should reference the others solution, instead of trying to supersede a subjective solutions. He the great 02:35, December 27, 2010 (UTC) Jesse Phillips
- I admit I did not look very carefully at the tip content. With a second look, it appears that the basic idea is different and valid–just remap hjkl and leave the rest alone–but the execution is very flawed. And the "Added Benefits" mappings make things even worse.
no d h " overrides delete (sort of OK, partially replaced with 'j') no h j " overrides left (OK) no S : " overrides change line (synonym for cc, probably OK) no j d " overrides down (ok), restores delete no l n " overrides right (ok) no n l " overrides next (sort of ok, partially replaced with l) no N <C-w><C-w> " overrides Previous, already replaced (sort of ok, replacement overrides useful function) no s : " overrides substitute letter, synonym for cl so maybe OK no _ ^ " no need, these are already synonyms no t k " overrides 'til no L N " overrides "Last" (bottom of current window) no - $ " little used function, but does override it no H 8<Down> " overrides "Home" (top of current window) no T 8<Up> " overrides 'Til no D <C-w><C-r> " overrides Delete to end of line
- Since you've expressed a desire to keep the tip, I'm somewhat inclined to do so, but I think it at least needs a dodgy flag. I'm adding that and removing the mapping for _ but the tip still needs work. As you say, I think BOTH tips are misguided and would frankly rather not have either. They do help some people though so I'm not going to remove the content entirely.
--Fritzophrenic 16:43, December 27, 2010 (UTC)