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.
