(Suggest CSApprox.vim over GuiColorScheme.vim) |
|||
| Line 35: | Line 35: | ||
==[[Using GUI color settings in a terminal]]== |
==[[Using GUI color settings in a terminal]]== |
||
| + | Well, it's definitely a useful tip. I think it's much better to recommend CSApprox over GuiColorScheme, but I might be biased since I'm the author. Here are a few reasons: |
||
| + | - Doesn't work by reading and parsing the colorscheme. GuiColorScheme gets confused by things as simple as leading spaces on :highlight lines, let alone conditionals, or a colorscheme that sources another then makes some small tweaks |
||
| + | - Works transparently, doesn't require a separate command to set the scheme, or a hack to load the plugin before plugins are normally loaded, and doesn't make any changes if the scheme is already high color or if the terminal doesn't support enough colors (though it warns loudly in that case). |
||
| + | - Handles 3 different 256-color palettes. It can handle choosing the correct colors even given the subtle differences between konsole, xterm, and Eterm's color palettes, as long as it knows what the terminal is (either because $TERM is set properly or a global variable is set saying "I'm a (konsole|eterm)". |
||
| + | - 90% as many downloads on vim.org as GuiColorScheme, and with a higher rating, despite being available for 1/4 the time. |
||
| + | The only disadvantage is that making it work in a vim without +gui requires running gvim and using :CSApproxSnapshot to dump out a version of the scheme that supports 88-/256-color terminals. CSApprox.vim works by querying the current gvim colors, and unfortunately this isn't possible where vim is -gui (yet, hopefully I can convince Bram to change that when I give him a patch). |
||
---- |
---- |
||
Revision as of 11:09, 15 March 2009
New tips March 2009
This is a place holder – not ready for use. Please wait until the end of March 2009 before editing this page because it is generated by a script, and any edits would be lost.
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.
Alternatively, comments can be posted on the mailing list.
| Proposed new tip | Current consensus |
|---|---|
| Make-compile current buffer | - |
| Using GUI color settings in a terminal | - |
Please add your comment (sign with ~~~~) below the appropriate heading. Use ---- between comments.
General comments (not for a specific tip)
Make-compile current buffer
Using GUI color settings in a terminal
Well, it's definitely a useful tip. I think it's much better to recommend CSApprox over GuiColorScheme, but I might be biased since I'm the author. Here are a few reasons:
- Doesn't work by reading and parsing the colorscheme. GuiColorScheme gets confused by things as simple as leading spaces on :highlight lines, let alone conditionals, or a colorscheme that sources another then makes some small tweaks - Works transparently, doesn't require a separate command to set the scheme, or a hack to load the plugin before plugins are normally loaded, and doesn't make any changes if the scheme is already high color or if the terminal doesn't support enough colors (though it warns loudly in that case). - Handles 3 different 256-color palettes. It can handle choosing the correct colors even given the subtle differences between konsole, xterm, and Eterm's color palettes, as long as it knows what the terminal is (either because $TERM is set properly or a global variable is set saying "I'm a (konsole|eterm)". - 90% as many downloads on vim.org as GuiColorScheme, and with a higher rating, despite being available for 1/4 the time.
The only disadvantage is that making it work in a vim without +gui requires running gvim and using :CSApproxSnapshot to dump out a version of the scheme that supports 88-/256-color terminals. CSApprox.vim works by querying the current gvim colors, and unfortunately this isn't possible where vim is -gui (yet, hopefully I can convince Bram to change that when I give him a patch).