Re: syntax - multiple colors in same string
subrama6 wrote: i'm somewhat new to vim, and particularly new to making my own syntax file, so please forgive me if this is a dumb question :) basically, i'm using vim to keep a GTD style todo list, with various tasks tagged by context. the format of the file is as follows: @vim @syntax : learn how to do write vim syntax files @vim @motions : learn more about motions @shopping @grocery : pick up bread on the way home ...etc these are all indented two spaces so that folding by indent works well for the various headings i've made. i've made a syntax file that does *almost* everything i want it to. the only thing i can't seem to get work is to get the tag identfier, namely @, to be a different, but specified, color than the text following it. here's what i mean. in the syntax file, i have something similar to the following syn match tag /\s@/ highlight link tag Special this makes the whole thing, @x, appear highlighted as Special. what i'd like to do, though, is have the @ be one color and the rest of the tag be another - Error, for example. I've tried the following: syn match tagtext /@[a-z]*/s+1 highlight link tagtext Error if the statements from above are in there, these lines appear not to make any difference. if they are not, the whole string gets highlighted as Error. I've tried multiple kinds of regexes, but it seems to me that when there are two that both have to do with the @, they seem to be clobbering each other. Any suggestions? What about syn match mysyntaxTag /\@\a*\/ contains=mysyntaxTagIdent syn match mysyntaxTagIdent /@/ contained hi default link mysyntaxTag Identifier hi default link mysyntaxTagIdent PreProc Note that by convention, any syntax groups that you create should start by the name (in lowercase) of the syntax script that created them; then comes the rest of the name (starting with a capital). This is meant to avoid clashes between scripts for different syntaxes. This convention is obeyed by any syntax script accepted in the main distribution, such as the conaryrecipe syntax currently being discussed on vim-dev. Best regards, Tony. -- Government lies, and newspapers lie, but in a democracy they are different lies.
Re: syntax - multiple colors in same string
that works well - i couldn't quite figure out what the 'contains' and 'contained' keywords were for just from the help files, so thanks much :) thanks also for the tip about the naming convention - i've amended my syntax file accordingly. A.J.Mechelynck wrote: subrama6 wrote: i'm somewhat new to vim, and particularly new to making my own syntax file, so please forgive me if this is a dumb question :) basically, i'm using vim to keep a GTD style todo list, with various tasks tagged by context. the format of the file is as follows: @vim @syntax : learn how to do write vim syntax files @vim @motions : learn more about motions @shopping @grocery : pick up bread on the way home ...etc these are all indented two spaces so that folding by indent works well for the various headings i've made. i've made a syntax file that does *almost* everything i want it to. the only thing i can't seem to get work is to get the tag identfier, namely @, to be a different, but specified, color than the text following it. here's what i mean. in the syntax file, i have something similar to the following syn match tag /\s@/ highlight link tag Special this makes the whole thing, @x, appear highlighted as Special. what i'd like to do, though, is have the @ be one color and the rest of the tag be another - Error, for example. I've tried the following: syn match tagtext /@[a-z]*/s+1 highlight link tagtext Error if the statements from above are in there, these lines appear not to make any difference. if they are not, the whole string gets highlighted as Error. I've tried multiple kinds of regexes, but it seems to me that when there are two that both have to do with the @, they seem to be clobbering each other. Any suggestions? What about syn match mysyntaxTag /\@\a*\/ contains=mysyntaxTagIdent syn match mysyntaxTagIdent /@/ contained hi default link mysyntaxTag Identifier hi default link mysyntaxTagIdent PreProc Note that by convention, any syntax groups that you create should start by the name (in lowercase) of the syntax script that created them; then comes the rest of the name (starting with a capital). This is meant to avoid clashes between scripts for different syntaxes. This convention is obeyed by any syntax script accepted in the main distribution, such as the conaryrecipe syntax currently being discussed on vim-dev. Best regards, Tony. -- Government lies, and newspapers lie, but in a democracy they are different lies. -- View this message in context: http://www.nabble.com/syntax---multiple-colors-in-same-string-tf3653839.html#a10218189 Sent from the Vim - General mailing list archive at Nabble.com.
Re: syntax - multiple colors in same string
subrama6 wrote: that works well - i couldn't quite figure out what the 'contains' and 'contained' keywords were for just from the help files, so thanks much :) thanks also for the tip about the naming convention - i've amended my syntax file accordingly. [...] Well, picture these syntax items as just that: a container and something contained in it. So we see @tagname -- mysyntaxTag ^--- (one character) mysyntaxTagIdent, inside the bigger one Vim highlights the whole in mysyntaxTag color, then overlays the @ in mysyntaxTagIdent color (only for @ within mysyntaxTag items because of the contains/contained clauses, and the syntax for mysyntaxTag requires @ as the first character and nowhere else). So you see the @ in one color and the rest in another color. Best regards, Tony. -- Laissez Faire Economics is the theory that if each acts like a vulture, all will end as doves.
syntax - multiple colors in same string
i'm somewhat new to vim, and particularly new to making my own syntax file, so please forgive me if this is a dumb question :) basically, i'm using vim to keep a GTD style todo list, with various tasks tagged by context. the format of the file is as follows: @vim @syntax : learn how to do write vim syntax files @vim @motions : learn more about motions @shopping @grocery : pick up bread on the way home ...etc these are all indented two spaces so that folding by indent works well for the various headings i've made. i've made a syntax file that does *almost* everything i want it to. the only thing i can't seem to get work is to get the tag identfier, namely @, to be a different, but specified, color than the text following it. here's what i mean. in the syntax file, i have something similar to the following syn match tag /\s@/ highlight link tag Special this makes the whole thing, @x, appear highlighted as Special. what i'd like to do, though, is have the @ be one color and the rest of the tag be another - Error, for example. I've tried the following: syn match tagtext /@[a-z]*/s+1 highlight link tagtext Error if the statements from above are in there, these lines appear not to make any difference. if they are not, the whole string gets highlighted as Error. I've tried multiple kinds of regexes, but it seems to me that when there are two that both have to do with the @, they seem to be clobbering each other. Any suggestions? -- View this message in context: http://www.nabble.com/syntax---multiple-colors-in-same-string-tf3653839.html#a10207707 Sent from the Vim - General mailing list archive at Nabble.com.
Re: completion menu colors
[EMAIL PROTECTED] wrote: fREW [EMAIL PROTECTED] 写于 2007-04-03 10:56:11: Are these things that should be set in the colorschemes, but just aren't yet because the names are new, or what? -fREW This should be set in colorscheme, however, if you're using the default colorschme it is buit-in with Vim and you cannot change the source code of colorscheme. If you are not using the default colorscheme, then you can just edit the colorscheme and set those settings. Note: a colorscheme does not have to set all the highlight settings, the settings which are not set inside a colorscheme will use the default. -- Sincerely, Pan, Shi Zhu. ext: 2606 To edit a colorscheme, first copy it under a different name into $HOME/.vim/colors (on Unix) or $HOME/vimfiles/colors (in Vim notation, for Windows). Any changes you make in the directory tree starting at $VIMRUNTIME may be overwritten without warning by any future upgrade of Vim, and the $VIMRUNTIME tree will in any case be recreated from scratch the day you install Vim 7.1 or Vim 8. By that time you will probably have forgotten the details of your changes, if you made any. Best regards, Tony.
Re: completion menu colors
fREW wrote: Is there a way to change the completion menu colors? Sure - see http://vim.sourceforge.net/scripts/script.php?script_id=1081 which both displays the current colors in whatever colorscheme you're using, plus provides a colorscheme editor (just rightmouse click on a color). The colors you're interested in changing are: Pmenu PmenuSbar PmenuSel PmenuThumb . (A leftmouse click on a color jumps the associated bit of text in the help describing the highlight's purpose). To invoke: :help hicolors Regards, Chip Campbell
completion menu colors
Hi all, Is there a way to change the completion menu colors? -fREW
RE: completion menu colors
Is there a way to change the completion menu colors? See: :help hl-Pmenu :help hl-PmenuSel :help hl-Pmenu-Sbar :help hl-PmenuThumb For example: :highlight Pmenu guibg=DarkRed cheers
Re: completion menu colors
--- fREW [EMAIL PROTECTED] wrote: Hi all, Is there a way to change the completion menu colors? Change the highlighting options for the Pmenu* highlight groups: :hi Pmenu ctermfg=Cyanctermbg=Blue cterm=None guifg=Cyan guibg=DarkBlue :hi PmenuSel ctermfg=White ctermbg=Blue cterm=Bold guifg=White guibg=DarkBlue gui=Bold :hi PmenuSbar ctermbg=Cyanguibg=Cyan :hi PmenuThumb ctermfg=White guifg=White etc. The 'cterm*' settings are for colour terminal, the 'gui*' settings are for GUI. You can see all colour groups by using ':runtime syntax/hitest.vim', or in GUI Vim use the menu selection Syntax - Highlight Test. regards, Peter Send instant messages to your online friends http://au.messenger.yahoo.com
Re: completion menu colors
On 4/2/07, Peter Hodge [EMAIL PROTECTED] wrote: --- fREW [EMAIL PROTECTED] wrote: Hi all, Is there a way to change the completion menu colors? Change the highlighting options for the Pmenu* highlight groups: :hi Pmenu ctermfg=Cyanctermbg=Blue cterm=None guifg=Cyan guibg=DarkBlue :hi PmenuSel ctermfg=White ctermbg=Blue cterm=Bold guifg=White guibg=DarkBlue gui=Bold :hi PmenuSbar ctermbg=Cyanguibg=Cyan :hi PmenuThumb ctermfg=White guifg=White etc. The 'cterm*' settings are for colour terminal, the 'gui*' settings are for GUI. You can see all colour groups by using ':runtime syntax/hitest.vim', or in GUI Vim use the menu selection Syntax - Highlight Test. regards, Peter Are these things that should be set in the colorschemes, but just aren't yet because the names are new, or what? -fREW
Re: completion menu colors
fREW [EMAIL PROTECTED] 写于 2007-04-03 10:56:11: Are these things that should be set in the colorschemes, but just aren't yet because the names are new, or what? -fREW This should be set in colorscheme, however, if you're using the default colorschme it is buit-in with Vim and you cannot change the source code of colorscheme. If you are not using the default colorscheme, then you can just edit the colorscheme and set those settings. Note: a colorscheme does not have to set all the highlight settings, the settings which are not set inside a colorscheme will use the default. -- Sincerely, Pan, Shi Zhu. ext: 2606
dos32 colors
Hi all! In color xterm color 1 for is #0c (red), but in dos32 it is #0c (blue). (Strictly speaking, VGA standard palette is different, but xterm colors are good enough approximation in practice). This makes very hard to write portable scripts dealing with colors. Does a better way to write a such a script exist other than: if has(dos32) let color1 = #0c else let color1 = #0c endif ? By the way, 2html.vim does not perform this test and colors of HTML generated in dos32 are wrong. -- Cyril Slobin [EMAIL PROTECTED] `When I use a word,' Humpty Dumpty said, http://45.free.net/~slobin `it means just what I choose it to mean'
About colors in t_Co=8 terminals: IncSearch hi group
Hi all :)) I've noticed something weird regarding IncSearch and I don't know if the problem is that I've set up my colors badly or that just I don't understand how the highlight command works. My terminal is 8 colors. If I set my IncSearch highlight group to something like this: highlight IncSearch cterm=NONE colorfg=0 colorbg=1 and then I do an incremental search for a word that is already highlighted with a bold color in foreground (e.g. for a word that is highlighted like a group with cterm=bolg, colorfg=6, colorbg=6, which is an example I've used and tested to reproduce this), then the background color of that work is changed to the background color of IncSearch, but the foreground color is changed to the foreground color bolded!. Looks like the bold attribute for the searched word is not replaced by the NONE attribute, so the incremental search shows weird colors when used over bolded words. I've tested the other way around (IncSearch being bold and the searched word being cterm=NONE) and that works perfectly, the bold attribute replaces correctly the NONE attribute. Am I doing something wrong, my terminal definitions are screwed or is this just a feature of IncSearch? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Colors for make output in gvim
I moved to gvim from vim recently and there is an issue that is bugging me. When i did a make in vim I was able to see the output of the make program in color. In gvim, I see the control sequences for the colors printed out and no colors. Is there a way I can resolve this? -jacob
vimdiff same bg and fg colors
Thanks Tony and Brady. I got sufficient answers. Happy vimming, Ben K. Developer http://benix.tamu.edu
Re: per-window search highlighting/colors
Brian Lewis wrote: I'm editing a file and open a preview window. When I search with /, I'd like the main window to show highlighted matches, but for the preview window not to. nohlsearch seems to be global, so I can't :setl nohlsearch in the preview window to get what I want. Maybe there's a way to modify color scheme settings in the preview window to make highlighted matches look as if they aren't highlighted? Thanks for the help. / or ? search is always global (I mean, it searches within the current file only, but matches are highlighted in all windows); no luck there. Similarly, colorschemes, highlight groups, and the 'hlsearch' option are also global. If you want to un-highlight the search matches once you're done looking at them, you can use the :noh[lsearch] command (without :set); if you want to highlight the matches of different patterns to be highlighted in different colors, you can use the :match and :2match commands. These are all I can think of. see :help :nohlsearch :help :match :help :2match Best regards, Tony.
Re: per-window search highlighting/colors
On Tue, 26 Sep 2006 10:16:22 -0400 Benji Fisher [EMAIL PROTECTED] wrote: On Tue, Sep 26, 2006 at 12:27:39AM -0500, Brian Lewis wrote: I'm editing a file and open a preview window. When I search with /, I'd like the main window to show highlighted matches, but for the preview window not to. I cannot think of a way to do this. Syntax-based highlighting is local to the buffer, so it can be changed for the preview window, but the Search highlight group is not syntax-based. http://www.vim.org/scripts/script.php?script_id=321 is almost what I need. With it, :Bs pattern highlights pattern in just the current window. Can I redefine / to use Bs?
Re: per-window search highlighting/colors
On Tue, Sep 26, 2006 at 12:27:39AM -0500, Brian Lewis wrote: I'm editing a file and open a preview window. When I search with /, I'd like the main window to show highlighted matches, but for the preview window not to. nohlsearch seems to be global, so I can't :setl nohlsearch in the preview window to get what I want. Maybe there's a way to modify color scheme settings in the preview window to make highlighted matches look as if they aren't highlighted? Thanks for the help. I cannot think of a way to do this. Syntax-based highlighting is local to the buffer, so it can be changed for the preview window, but the Search highlight group is not syntax-based. --Benji Fisher
Re: per-window search highlighting/colors
On 9/26/06, Brian Lewis [EMAIL PROTECTED] wrote: On Tue, 26 Sep 2006 10:16:22 -0400 Benji Fisher [EMAIL PROTECTED] wrote: On Tue, Sep 26, 2006 at 12:27:39AM -0500, Brian Lewis wrote: I'm editing a file and open a preview window. When I search with /, I'd like the main window to show highlighted matches, but for the preview window not to. I cannot think of a way to do this. Syntax-based highlighting is local to the buffer, so it can be changed for the preview window, but the Search highlight group is not syntax-based. http://www.vim.org/scripts/script.php?script_id=321 is almost what I need. With it, :Bs pattern highlights pattern in just the current window. Can I redefine / to use Bs? :nmap / :Bsspace Yakov
per-window search highlighting/colors
I'm editing a file and open a preview window. When I search with /, I'd like the main window to show highlighted matches, but for the preview window not to. nohlsearch seems to be global, so I can't :setl nohlsearch in the preview window to get what I want. Maybe there's a way to modify color scheme settings in the preview window to make highlighted matches look as if they aren't highlighted? Thanks for the help.
Re: Why is after/colors/colorscheme.vim disabled?
Peter Hodge wrote: Hello, I am just curious as to why after/colors/ scripts are disabled instead of behaving like after/ftplugin and after/syntax scripts? regards, Peter I'm not sure if it's a bug or a feature, but :colorscheme foobar works like :runtime colors/foobar.vim with no exclamation mark after :runtime. To use ~/.vim/colors/foobar.vim as a user addition to $VIMRUNTIME/colors/foobar.vim, invoke it with :runtime! colors/foobar.vim (with exclamation mark) instead. You might even want to define a user-command :command ColorScheme -nargs=1 runtime! colors/args.vim See :help :runtime Best regards, Tony.
Re: Why is after/colors/colorscheme.vim disabled?
On 8/21/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Peter Hodge wrote: Hello, I am just curious as to why after/colors/ scripts are disabled instead of behaving like after/ftplugin and after/syntax scripts? regards, Peter I'm not sure if it's a bug or a feature, but Every bug is a feature. :-) :colorscheme foobar works like :runtime colors/foobar.vim with no exclamation mark after :runtime. To use ~/.vim/colors/foobar.vim as a user addition to $VIMRUNTIME/colors/foobar.vim, invoke it with :runtime! colors/foobar.vim (with exclamation mark) instead. You might even want to define a user-command :command ColorScheme -nargs=1 runtime! colors/args.vim See :help :runtime Best regards, Tony.
Re: colors
If you find the syntax file for Vim 6.4, and put it into your own .vim directory, you may get the colors before. If you want to change it, just copy the syntax file into your own .vim directory and edit it. -- Sincerely, Pan, Shi Zhu. ext: 2606 Bill Hollingsworth [EMAIL PROTECTED] wrote on 2006.07.18 04:53:57: Hi, I recently upgraded to VIM 7.0 and now the color settings for my PERL programs are different. I liked the way the colors were before. Could someone tell me how to return to the old settings, or how to set the colors myself? For instance, now comments and variable names are the same color. Thanks and best wishes, Bill Hollingsworth University of Cambridge Computer Laboratory
Re: colors
As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall On Jul 17, 2006, at 7:01 PM, A.J.Mechelynck wrote: Bill Hollingsworth wrote: Hi, I recently upgraded to VIM 7.0 and now the color settings for my PERL programs are different. I liked the way the colors were before. Could someone tell me how to return to the old settings, or how to set the colors myself? For instance, now comments and variable names are the same color. Thanks and best wishes, Bill Hollingsworth University of Cambridge Computer Laboratory I guess the easiest way is to write your own colorscheme. For instance I use the attached colorscheme which I wrote, named $HOME/.vim/colors/almost-default.vim and invoked by :colorscheme almost-default. It is a simple example which might help you create your own. You will have to find out the names of the highlight groups for which you need a non-default color. (Try Comment and Identifier; I guess changing them will also change perlComment and PerlIdentifier, or however they are named). You can set different colors for console Vim and gvim by using, in the same :highlight command, arguments cterm= ctermfg= ctermbg= on the one hand, and gui= guibg= guifg= onthe other hand. There are also a number of colorschemes available in your distribution (in $VIMRUNTIME/colors) and at vim-online (which can be installed by dropping them in one of the following: - system-wide: $VIM/vimfiles/colors - user-private on Unix: ~/.vim/colors - user-private on Windows: ~/vimfiles/colors ). Don't change anything in $VIMRUNTIME or its subdirs, because any upgrade can silently overwrite any changes you made there. See :help :highlight :help :colorscheme :view $VIMRUNTIME/colors/README.txt HTH, Tony. Vim color file Maintainer: Tony Mechelynck [EMAIL PROTECTED] Last Change: 2006 Jun 21 This is almost the default color scheme. It doesn't define the Normal highlighting, it uses whatever the colors used to be. Only the few highlight groups named below are defined; the rest (most of them) are left at their compiled-in default settings. Set 'background' back to the default. The value can't always be estimated and is then guessed. hi clear Normal set bg Remove all existing highlighting and set the defaults. hi clear Load the syntax highlighting defaults, if it's enabled. if exists(syntax_on) syntax reset endif Set our own highlighting settings hi Errorguibg=red guifg=black hi clear ErrorMsg hi link ErrorMsg Error hi StatusLine gui=NONE,bold guibg=red guifg=white hi StatusLineNC gui=reverse,bold hi TabLine gui=NONEguibg=#DD guifg=black hi TabLineFill gui=NONEguibg=#AA guifg=red hi User1ctermfg=magenta guibg=white guifg=magenta hi User2ctermfg=darkmagenta guibg=#DD guifg=magenta remember the current colorscheme name let colors_name = almost-default vim: sw=2
Re: colors
Marshall Abrams wrote: As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall My answer to that (and it is a personal opinion, not a dogma) is that most of the alphabetic keys (with or without Shift or Ctrl) are already assigned in standard Vim (including gg for go to top if you don't like the hand movement and Shift chord required by 1G), and more of them if possible are likely to get mapped in the future, so it's risky business at best to try mapping one's own functions to them. An infamous example of the latter is the mswin.vim plugin, which overrides several of the Ctrl-letter keys with its own Windows-like mappings, thus obliterating many useful Vim keystrokes. OTOH, the F keys (other than F1 and sometimes F10) are available by default; so my advice is to map user-defined mappings to F keys with or without Shift/Ctrl/Alt, and mappings defined in unofficial plugins to multikey sequences starting with Leader LocalLeader etc. Best regards, Tony.
Key mappings (was: Re: colors)
On Jul 18, 2006, at 2:33 PM, A.J.Mechelynck wrote: Marshall Abrams wrote: As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall My answer to that (and it is a personal opinion, not a dogma) is that most of the alphabetic keys (with or without Shift or Ctrl) are already assigned in standard Vim I have noticed that, but I'm not a fan of it. Fortunately, I rarely need the functions assigned to g+something. I occasionally undo my q mapping in order to record a macro. (including gg for go to top if you don't like the hand movement and Shift chord required by 1G), and more of them if possible are likely to get mapped in the future, so it's risky business at best to try mapping one's own functions I was mapping g long before vim started mapping things to it. So from my point of view, it was the developers who engaged in risky behavior. (Let me emphasize that I remain extremely grateful.) to them. An infamous example of the latter is the mswin.vim plugin, which overrides several of the Ctrl-letter keys with its own Windows-like mappings, thus obliterating many useful Vim keystrokes. OTOH, the F keys (other than F1 and sometimes F10) are available by default; so my advice is to map user-defined mappings to F keys with or without Shift/Ctrl/Alt, and mappings defined in unofficial plugins to multikey sequences starting with Leader LocalLeader etc. Uggh. F-keys. That's why I kept using Emacs for a long time. Why I switched to vi for even greater ease. So my fingers wouldn't have to leave the letter keys. (Esc is an exception, but easy to slap.) Same reason I don't like editors that make essential use of the mouse. Let nothing intervene between thought and text. Best regards, Tony. Oh well. Thanks Tony. Marshall
RE: colors
I am afraid that I have to agree with the complaint against drastically changing the default color scheme. As a sight-impaired user I relied on the color scheme that I was using before version 7.0. I did not create it myself; I developed my own convention for using the color scheme that was there as a default. Now that the colors have change in a bad way (e.g. PERL comments are the same color as PERL variables) I do not have time to invest in learning how to program a new color scheme. My only solution right now is to try to uninstall VIM and reinstall the old version. For future versions I would encourage developers to offer changes to default settings only as an option. There is of course the standards issue, but there is also an accessibility issue that might not have been considered. Bill Hollingsworth University of Cambridge Computer Laboratory Original Message Subject: Re: colors From: A.J.Mechelynck [EMAIL PROTECTED] Date: Tue, July 18, 2006 7:33 pm To: Marshall Abrams [EMAIL PROTECTED] Cc: vim@vim.org Marshall Abrams wrote: As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall My answer to that (and it is a personal opinion, not a dogma) is that most of the alphabetic keys (with or without Shift or Ctrl) are already assigned in standard Vim (including gg for go to top if you don't like the hand movement and Shift chord required by 1G), and more of them if possible are likely to get mapped in the future, so it's risky business at best to try mapping one's own functions to them. An infamous example of the latter is the mswin.vim plugin, which overrides several of the Ctrl-letter keys with its own Windows-like mappings, thus obliterating many useful Vim keystrokes. OTOH, the F keys (other than F1 and sometimes F10) are available by default; so my advice is to map user-defined mappings to F keys with or without Shift/Ctrl/Alt, and mappings defined in unofficial plugins to multikey sequences starting with Leader LocalLeader etc. Best regards, Tony.
RE: colors
Hi Bill, You do not have to program a new colorscheme. If you run this command: :source $VIMRUNTIME/syntax/hitest.vim ... you will get a window containing all the highlighting colours used by Vim. There's hundreds of colours listed, but there are prossibly only two that you want to change, under the 'Syntax Highlighting Groups' section. Add something like this to your ~/.vimrc change default colors for color terminal highlight Comment ctermfg=Blue cterm=Underline highlight Identifier ctermfg=Red cterm=Bold change default colors for GUI highlight Comment guifg=Blue gui=Underline highlight Identifier guifg=Red gui=Bold It shouldn't be too difficult to change those colors to something which works for you. I hope you don't have to go back to using Vim 6.4. I am afraid that I have to agree with the complaint against drastically changing the default color scheme. As a sight-impaired user I relied on the color scheme that I was using before version 7.0. I did not create it myself; I developed my own convention for using the color scheme that was there as a default. Now that the colors have change in a bad way (e.g. PERL comments are the same color as PERL variables) I do not have time to invest in learning how to program a new color scheme. My only solution right now is to try to uninstall VIM and reinstall the old version. I can see your point and it is concerning that the colour change is enough to force you to go back to Vim 6.4, but Bram (or any software package author) must reserve privileges to change things and make them the default, otherwise everyone gets a Vim 7.0 which behaves exactly like 6.4 and 70% of the user base doesn't have the time or knowledge to find and activate the new features. I regularly confront this issue as I write the PHP syntax as I must decided whether to A) make a feature ON by default and frustrate lots of people; or B) make a feature OFF by default so that no one gets annoyed, but risk that many people will miss out on that feature because they don't know how to turn it on. regards, Peter On Yahoo!7 Messenger - Make free PC-to-PC calls to your friends overseas. http://au.messenger.yahoo.com
RE: colors
Peter Hodge [EMAIL PROTECTED] wrote on 2006.07.19 09:32:47: I can see your point and it is concerning that the colour change is enough to force you to go back to Vim 6.4, but Bram (or any software package author) must reserve privileges to change things and make them the default, otherwise everyone gets a Vim 7.0 which behaves exactly like 6.4 and 70% of the user base doesn't have the time or knowledge to find and activate the new features. I regularly confront this issue as I write the PHP syntax as I must decided whether to A) make a feature ON by default and frustrate lots of people; or B) make a feature OFF by default so that no one gets annoyed, but risk that many people will miss out on that feature because they don't know how to turn it on. regards, Peter Hi Peter, My opinion is: if I can live with the previous version, then that's it, and I certainly can live with the new version without the new features turn on by default. If there is something I cannot live with in the previous version, or if I feel I must have the new feature, then I will try to find how to turn it on. Any way, Vim is not an editor which people can learn without any effort, do you think those who are willing to spend time to learn Vim do not want to learn the new features they DO want? If I do really want the feature, I will try to find how to turn it on, otherwise, I'd rather the authors just leave it OFF. For example, after installed Vim 7.0 I found the cursor movement become unacceptably slow, I spend too much time, finally I found its due to the matchparen plugin, and I spend much more time to find how to disable it in an elegant way. if the new feature are OFF by default, my life would have been much easier. Again, after installed Vim 7.0, the VisVim behaves strange, and have a high chance not opening the specified file at all. I don't know where the problem is, so I have to use Vim 6.4 with VS.
Re: colors
Bill Hollingsworth wrote: Hi, I recently upgraded to VIM 7.0 and now the color settings for my PERL programs are different. I liked the way the colors were before. Could someone tell me how to return to the old settings, or how to set the colors myself? For instance, now comments and variable names are the same color. Thanks and best wishes, Bill Hollingsworth University of Cambridge Computer Laboratory I guess the easiest way is to write your own colorscheme. For instance I use the attached colorscheme which I wrote, named $HOME/.vim/colors/almost-default.vim and invoked by :colorscheme almost-default. It is a simple example which might help you create your own. You will have to find out the names of the highlight groups for which you need a non-default color. (Try Comment and Identifier; I guess changing them will also change perlComment and PerlIdentifier, or however they are named). You can set different colors for console Vim and gvim by using, in the same :highlight command, arguments cterm= ctermfg= ctermbg= on the one hand, and gui= guibg= guifg= onthe other hand. There are also a number of colorschemes available in your distribution (in $VIMRUNTIME/colors) and at vim-online (which can be installed by dropping them in one of the following: - system-wide: $VIM/vimfiles/colors - user-private on Unix: ~/.vim/colors - user-private on Windows: ~/vimfiles/colors ). Don't change anything in $VIMRUNTIME or its subdirs, because any upgrade can silently overwrite any changes you made there. See :help :highlight :help :colorscheme :view $VIMRUNTIME/colors/README.txt HTH, Tony. Vim color file Maintainer: Tony Mechelynck [EMAIL PROTECTED] Last Change: 2006 Jun 21 This is almost the default color scheme. It doesn't define the Normal highlighting, it uses whatever the colors used to be. Only the few highlight groups named below are defined; the rest (most of them) are left at their compiled-in default settings. Set 'background' back to the default. The value can't always be estimated and is then guessed. hi clear Normal set bg Remove all existing highlighting and set the defaults. hi clear Load the syntax highlighting defaults, if it's enabled. if exists(syntax_on) syntax reset endif Set our own highlighting settings hi Errorguibg=red guifg=black hi clear ErrorMsg hi link ErrorMsg Error hi StatusLine gui=NONE,bold guibg=red guifg=white hi StatusLineNC gui=reverse,bold hi TabLine gui=NONEguibg=#DD guifg=black hi TabLineFill gui=NONEguibg=#AA guifg=red hi User1ctermfg=magenta guibg=white guifg=magenta hi User2ctermfg=darkmagenta guibg=#DD guifg=magenta remember the current colorscheme name let colors_name = almost-default vim: sw=2
Changing spell check colors
Using spell check in a terminal window hightlights some words with a bright green background and white text. I find this hard to read (I'm using a dark background and I have set background=dark in my .vimrc). Is it possible to override the the spell check color scheme, and if so, can someone please point me in the direction of what I need to look at? Thanx! Chris -- Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org
Re: Changing spell check colors
On 7/7/06, Chris Sutcliffe [EMAIL PROTECTED] wrote: Using spell check in a terminal window hightlights some words with a bright green background and white text. I find this hard to read (I'm using a dark background and I have set background=dark in my .vimrc). Is it possible to override the the spell check color scheme, and if so, can someone please point me in the direction of what I need to look at? You need to define following highlighting groups: SpellBad SpellCap SpellRare SpellLocal For example, in my setup SpellBad is defined as SpellBad xxx term=reverse ctermbg=1 gui=undercurl guisp=Red -- shows as gray on red background To learn how to write your own :highlight commands 1) :highlight - instructive, shows existing highlight groups :hi 2) :help :hi 3) To check how Spell-related groups are defined: :hi SpellBad :hi SpellCap :hi SpellRare :hi SpellLocal Yakov
Re: Changing spell check colors
Chris Sutcliffe wrote: Using spell check in a terminal window hightlights some words with a bright green background and white text. I find this hard to read (I'm using a dark background and I have set background=dark in my .vimrc). Is it possible to override the the spell check color scheme, and if so, can someone please point me in the direction of what I need to look at? If you use the following plugin: http://vim.sourceforge.net/scripts/script.php?script_id=1081 and then type :help hicolors you'll see each highlighting color name in its own colors. This list includes SpellBad SpellCap SpellLocal SpellRare If you then right click on any of the names, a colorscheme editor will pop up for that color. Edit it, save it, use it! Regards, Chip Campbell
colors in vim
This is a basic question, but I still could not figure out how to do it: I am unable to get colors for my vim editor on some of the cluster machines in my university. Vim is using underlining and bold-font to highlight language keywords and comments. How can I get vim to use colors instead of underlining and bold-font. thanks in advance! Sorav
Re: colors in vim
Thanks for the quick help. Here are the answers to the checklist: 1. Your terminal emulator must support color. - Does the terminal show colors for other applications? Yes, it shows colors for 'ls -- color' 2. The TERM environment variable must be set to the type of terminal emulator you are using. - From a shell prompt, what does echo $TERM show? $TERM = xterm 3. The terminfo database for $TERM must be correct and must indicate that the terminal supports color. - From a shell prompt, if you execute infocmp or untic (depending on your flavor of Unix) you should see some cryptic looking stuff including colors#8, colors#16, or colors#256 in the second or third line. If you don't, then your terminfo database is telling vim that your terminal doesn't support color. I don't see any 'colors#' in my infocmp output. This seems to be a problem. 4. Vim must be built with a termlib that supports color. - From withing vim, execute :set termcap and look for the t_Co= value. It should be the same as the colors# from the terminfo database. If the entry is empty or 0, then your termlib may be broken and you may need to recompile vim (if you can) with a different termlib. (HP-UX 10.20 has this problem.) t_Co is blank. Problems 3 and 4 can be worked around by following the instructions in :help xterm-color. I tried using set t_Sf=Esc[3%p1%dm in my vimrc file, but instead of showing colors, it appends these characters to the keywords. For example: Esc[32mvoid thanks for your help again! Sorav
Re: colors in vim
On 2006-04-14, Sorav Bansal [EMAIL PROTECTED] wrote: Thanks for the quick help. Here are the answers to the checklist: 1. Your terminal emulator must support color. - Does the terminal show colors for other applications? Yes, it shows colors for 'ls -- color' 2. The TERM environment variable must be set to the type of terminal emulator you are using. - From a shell prompt, what does echo $TERM show? $TERM = xterm 3. The terminfo database for $TERM must be correct and must indicate that the terminal supports color. - From a shell prompt, if you execute infocmp or untic (depending on your flavor of Unix) you should see some cryptic looking stuff including colors#8, colors#16, or colors#256 in the second or third line. If you don't, then your terminfo database is telling vim that your terminal doesn't support color. I don't see any 'colors#' in my infocmp output. This seems to be a problem. The terminfo database is usually found in /usr/lib/terminfo or /usr/share/lib/terminfo. If you do an 'ls' in the 'x' subdirectory, you'll see the available xterm terminal types. If you see xterm-color or xterm-16color there, try setting TERM to one of those names and try vim again. 4. Vim must be built with a termlib that supports color. - From withing vim, execute :set termcap and look for the t_Co= value. It should be the same as the colors# from the terminfo database. If the entry is empty or 0, then your termlib may be broken and you may need to recompile vim (if you can) with a different termlib. (HP-UX 10.20 has this problem.) t_Co is blank. Problems 3 and 4 can be worked around by following the instructions in :help xterm-color. I tried using set t_Sf=Esc[3%p1%dm in my vimrc file, but instead of showing colors, it appends these characters to the keywords. For example: Esc[32mvoid Did you use a real escape character as noted just below the endif in that :help entry, or did you use the five characters Esc? HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: colors in vim
Did you use a real escape character as noted just below the endif in that :help entry, or did you use the five characters Esc? Great! It worked! Thanks a ton! Sorav
