Please use this page to discuss pages that have been labeled for deletion.
Archives: 1 • 2 • 3 • 4 • 5 • 6 • 7 • 8
- 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))
- 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 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)