Re: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: Hello vimmers, I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... When I build Vim I always have to copy in an rgb.txt file that I have into the runtime. Otherwise I get those errors. Robert
Re: 7.1a.001 OSX colour scheme errors?
Tony Mechelynck wrote: > Bram Moolenaar wrote: > [...] > > I'll add a specific line to copy rgb.txt. > > > > Just for the record, after reformatting the entries to a common format and > sorting, a diff between my ~/.build/vim/vim71a/runtime/rgb.txt and my > /usr/share/X11/rgb.txt shows no other difference than the header comment -- > so > I suppose copying it unconditionally oughtn't to harm the OSs where there > already is an rgb.txt. Unless someone has an enhanced rgb.txt... > Oh, and just for fun: I slapped together a syntax script for rgb.txt > (attached). I use it with a zero-length ftplugin and a one-line detection > autocommand in filetype.vim (which are not attached: the autocommand is: "au > BufRead,BufNewFile rgb.txt setf rgb"); Bram, what do you think of it? Looks good. But I'll include it later. Needs some testing first. -- >From "know your smileys": :-EHas major dental problems /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: 7.1a.001 OSX colour scheme errors?
Bram Moolenaar wrote: [...] I'll add a specific line to copy rgb.txt. Just for the record, after reformatting the entries to a common format and sorting, a diff between my ~/.build/vim/vim71a/runtime/rgb.txt and my /usr/share/X11/rgb.txt shows no other difference than the header comment -- so I suppose copying it unconditionally oughtn't to harm the OSs where there already is an rgb.txt. Oh, and just for fun: I slapped together a syntax script for rgb.txt (attached). I use it with a zero-length ftplugin and a one-line detection autocommand in filetype.vim (which are not attached: the autocommand is: "au BufRead,BufNewFile rgb.txt setf rgb"); Bram, what do you think of it? Best regards, Tony. " Syntax plugin for rgb (rgb.txt) files " Language: rgb.txt " Maintainer: Tony Mechelynck <[EMAIL PROTECTED]> " Last Change: 9 May 2007 sy match rgbError /^.*$/ hi def link rgbError Error sy match rgbComment /^!.*$/ display hi def link rgbComment Comment sy match rgbLine transparent /^\s*\d\+\s\+\d\+\s\+\d\+\s\+\a.*$/ contains=rgbNumber,rgbName sy match rgbNumber /\<\d\+\>/ contained hi def link rgbNumber Number sy match rgbName /\<\a.*$/ contained hi def link rgbName Identifier
RE: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: > > > Has anyone else noticed this? > > > > You apparently are missing the runtime/rgb.txt file. It's part of the > > extra archive. Perhaps you didn't unpack it correctly? You must have > > unpacked it, since it contains src/gui_mac.c. And you must not change > > the directory structure, otherwise Vim.app can't be generated > > correctly. > > I have the rgb.txt in my build tree. Its just that 'make install' > doesn't copy it over when building Vim.App. See further on in this > thread with the subject "[SOLVED] RE: 7.1a.001 OSX colour scheme > errors?". > > Is it possible for you to change the Makefile to copy rgb.txt to > $VIMRUNTIME during 'make install'? OK, I was trying the Vim.app after building it. Then it uses a link to the runtime files, thus rgb.txt is there. I'll add a specific line to copy rgb.txt. -- I AM THANKFUL... ...for the clothes that fit a little too snug because it means I have more than enough to eat. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
RE: 7.1a.001 OSX colour scheme errors?
> > Has anyone else noticed this? > > You apparently are missing the runtime/rgb.txt file. It's part of the > extra archive. Perhaps you didn't unpack it correctly? You must have > unpacked it, since it contains src/gui_mac.c. And you must not change > the directory structure, otherwise Vim.app can't be generated > correctly. I have the rgb.txt in my build tree. Its just that 'make install' doesn't copy it over when building Vim.App. See further on in this thread with the subject "[SOLVED] RE: 7.1a.001 OSX colour scheme errors?". Is it possible for you to change the Makefile to copy rgb.txt to $VIMRUNTIME during 'make install'? Thanks.
Re: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: > I am running 7.1a.001 on OSX and have just noticed the following from > console vim (running in Terminal.app and also occurs in iTerm.app). > > If I change the colour scheme I receive a lot of error output. For > example: > > :colorscheme desert > > Results in: > > Error detected while processing > /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: > line 27: > E254: Cannot allocate color khaki > E254: Cannot allocate color slategrey > line 36: > E254: Cannot allocate color gold > line 37: > E254: Cannot allocate color tan > ... > > Other colour schemes produce similar output. The error messages have > only appeared for me in console vim on OSX (10.4.9 PPC). They have not > appeared in the linux or win32 console vims of 7.1a.001. GVim's on each > of the platforms (OSX, linux, Win32) have worked fine. > > My console vim is symlinked as follows: > > $ ls -l `which vim` > lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim -> > /Applications/Vim.app/Contents/MacOS/Vim > > These errors did not occur before 7.1a.001 and occurs on builds from CVS > and SVN. The errors still occur even with starting vim with: > > vim -u NONE > > Has anyone else noticed this? You apparently are missing the runtime/rgb.txt file. It's part of the extra archive. Perhaps you didn't unpack it correctly? You must have unpacked it, since it contains src/gui_mac.c. And you must not change the directory structure, otherwise Vim.app can't be generated correctly. -- >From "know your smileys": :-XMy lips are sealed /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
RE: [SOLVED] RE: 7.1a.001 OSX colour scheme errors?
> Michael Wookey wrote: > >> Hm... Maybe the console version checks the values of the guibg= > guifg= > >> settings even though it doesn't use them. Try dropping the attached > >> file into your $VIMRUNTIME folder and see if it makes any > difference. > >> > >> (See ":help rgb.txt" for an explanation of how Vim uses it. IIUC, on > >> X11- and Windows-based systems, those colour names' RGB values can > be > >> obtained by querying the OS.) > > > > Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to > > $VIMRUNTIME. > > > > It seems that this is a bug because even on the linux machine, 'make > > install' doesn't copy rgb.txt either. However on the linux machine > > there are existing copies of rgb.txt in places like /etc/x11/rgb.txt > > (Ubuntu 7.04) which vim must have picked up which is why it works. > > The help mentions /usr/X11R6/lib/X11/ ; I found mine in /usr/share/X11 > (on > SuSE 10.2)... Apparently there is no single fixed location for that > file. I > wonder what the rule is? Any app using colour names should be able to > find it > after all. On Ubuntu 7.04, the following are all symlinked to /etc/X11/rgb.txt /usr/share/X11/rgb.txt /usr/lib/X11/rgb.txt On OSX, there is no rgb.txt on the system at all unless X11 is installed (which it is not by default). This is why it may be a good thing to include rgb.txt for the OSX vim builds.
Re: [SOLVED] RE: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See ":help rgb.txt" for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to $VIMRUNTIME. It seems that this is a bug because even on the linux machine, 'make install' doesn't copy rgb.txt either. However on the linux machine there are existing copies of rgb.txt in places like /etc/x11/rgb.txt (Ubuntu 7.04) which vim must have picked up which is why it works. The help mentions /usr/X11R6/lib/X11/ ; I found mine in /usr/share/X11 (on SuSE 10.2)... Apparently there is no single fixed location for that file. I wonder what the rule is? Any app using colour names should be able to find it after all. I've never noticed this bug before since I always rsync the runtime after a build - which therefore places an rgb.txt into my $VIMRUNTIME. Because rsync is not suitable for the Vim 7.1a runtime, rgb.txt is missing from my $VIMRUNTIME hence the issue showed itself. I just did a build of 7.0.243 (svn#261) and it also fails with the inability to understand the colour scheme - because there is no rgb.txt copied to $VIMRUNTIME! So it looks like this might have been a long standing issue. Bram - can you change the Makefile to copy rgb.txt to $VIMRUNTIME for OSX builds? Thanks for the tip Tony! Best regards, Tony. -- ... Logically incoherent, semantically incomprehensible, and legally ... impeccable!
[SOLVED] RE: 7.1a.001 OSX colour scheme errors?
> Hm... Maybe the console version checks the values of the guibg= guifg= > settings even though it doesn't use them. Try dropping the attached > file into your $VIMRUNTIME folder and see if it makes any difference. > > (See ":help rgb.txt" for an explanation of how Vim uses it. IIUC, on > X11- and Windows-based systems, those colour names' RGB values can be > obtained by querying the OS.) Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to $VIMRUNTIME. It seems that this is a bug because even on the linux machine, 'make install' doesn't copy rgb.txt either. However on the linux machine there are existing copies of rgb.txt in places like /etc/x11/rgb.txt (Ubuntu 7.04) which vim must have picked up which is why it works. I've never noticed this bug before since I always rsync the runtime after a build - which therefore places an rgb.txt into my $VIMRUNTIME. Because rsync is not suitable for the Vim 7.1a runtime, rgb.txt is missing from my $VIMRUNTIME hence the issue showed itself. I just did a build of 7.0.243 (svn#261) and it also fails with the inability to understand the colour scheme - because there is no rgb.txt copied to $VIMRUNTIME! So it looks like this might have been a long standing issue. Bram - can you change the Makefile to copy rgb.txt to $VIMRUNTIME for OSX builds? Thanks for the tip Tony!
Re: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: A.J.Mechelynck wrote: Michael Wookey wrote: Hello vimmers, I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... Other colour schemes produce similar output. The error messages have only appeared for me in console vim on OSX (10.4.9 PPC). They have not appeared in the linux or win32 console vims of 7.1a.001. GVim's on each of the platforms (OSX, linux, Win32) have worked fine. My console vim is symlinked as follows: $ ls -l `which vim` lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim -> /Applications/Vim.app/Contents/MacOS/Vim These errors did not occur before 7.1a.001 and occurs on builds from CVS and SVN. The errors still occur even with starting vim with: vim -u NONE Has anyone else noticed this? These color names should be used only in the GUI. In the "desert" colorscheme I have (v1.1, 2004/06/13 19:30:30) they are only present in "guibg=" and "guifg=" arguments to the ":hi" command, which is normal. If you want to debug that problem, you may want to vimgrep your sources for the "highlight" command, then inspect the source to see if (as it should) it does ignore guibg= guifg= and gui= when setting highlights in Console Vim. You may restrict yourself to the modules which were actually compiled for your configure options, as shown e.g. by the contents of the objects folder (src/objects or whatever). I think I've found it.. The OSX Vim is built with FEAT_GUI_MAC always defined. This in turn forces FEAT_GUI to be defined. This is from around lines 66-102 of src/vim.h. In src/syntax.c:do_highlight() there are checks for FEAT_GUI to be defined. Items like "guifg" and "guibg" etc are conditionally compiled to only take effect if FEAT_GUI is defined (which it is in the OSX case). The call chain eventually looks like: do_highlight() color_name2handle() gui_get_color()<- E254: Cannot allocate color So because FEAT_GUI is always defined on OSX, vim gets these errors for console vim. I still don't quite understand why this is causing an error when it doesn't on linux. The console linux version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 8 2007 00:27:42) Included patches: 1 Huge version with GTK2 GUI. Features included (+) or not (-): ... While the console OSX version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 9 2007 11:33:38) MacOS X (unix) version Included patches: 1 Huge version with Carbon GUI. Features included (+) or not (-): ... So both have the GUI built in yet only the OSX version complains about the colour scheme being set. Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See ":help rgb.txt" for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Best regards, Tony. -- All this wheeling and dealing around, why, it isn't for money, it's for fun. Money's just the way we keep score. ! $Xorg: rgb.txt,v 1.3 2000/08/17 19:54:00 cpqbld Exp $ 255 250 250 snow 248 248 255 ghost white 248 248 255 GhostWhite 245 245 245 white smoke 245 245 245 WhiteSmoke 220 220 220 gainsboro 255 250 240 floral white 255 250 240 FloralWhite 253 245 230 old lace 253 245 230 OldLace 250 240 230 linen 250 235 215 antique white 250 235 215 AntiqueWhite 255 239 213 papaya whip 255 239 213 PapayaWhip 255 235 205 blanched almond 255 235 205 BlanchedAlmond 255 228 196 bisque 255 218 185 peach puff 255 218 185 PeachPuff 255 222 173 navajo white 255 222 173 NavajoWhite 255 228 181 moccasin 255 248 220 cornsilk 255 255 240 ivory 255 250 205 lemon chiffon 255 250 205 LemonChiffon 255 245 238 seashell 240 255 240 honeydew 245 255 250 mint cream 245 255 250 MintCream 240 255 255 azure 240 248 255 alice blue 240 248 255 AliceBlue 230 230 250 lavender 255 240 245 la
RE: 7.1a.001 OSX colour scheme errors?
> A.J.Mechelynck wrote: > > Michael Wookey wrote: > > Hello vimmers, > > > > I am running 7.1a.001 on OSX and have just noticed the following from > > console vim (running in Terminal.app and also occurs in iTerm.app). > > > > If I change the colour scheme I receive a lot of error output. For > > example: > > > > :colorscheme desert > > > > Results in: > > > > Error detected while processing > > > /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: > > line 27: > > E254: Cannot allocate color khaki > > E254: Cannot allocate color slategrey > > line 36: > > E254: Cannot allocate color gold > > line 37: > > E254: Cannot allocate color tan > > ... > > > > Other colour schemes produce similar output. The error messages have > > only appeared for me in console vim on OSX (10.4.9 PPC). They have > not > > appeared in the linux or win32 console vims of 7.1a.001. GVim's on > each > > of the platforms (OSX, linux, Win32) have worked fine. > > > > My console vim is symlinked as follows: > > > > $ ls -l `which vim` > > lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim -> > > /Applications/Vim.app/Contents/MacOS/Vim > > > > These errors did not occur before 7.1a.001 and occurs on builds from > CVS > > and SVN. The errors still occur even with starting vim with: > > > > vim -u NONE > > > > Has anyone else noticed this? > > > > > > These color names should be used only in the GUI. In the "desert" > colorscheme > I have (v1.1, 2004/06/13 19:30:30) they are only present in "guibg=" > and > "guifg=" arguments to the ":hi" command, which is normal. > > If you want to debug that problem, you may want to vimgrep your sources > for > the "highlight" command, then inspect the source to see if (as it > should) it > does ignore guibg= guifg= and gui= when setting highlights in Console > Vim. > > You may restrict yourself to the modules which were actually compiled > for your > configure options, as shown e.g. by the contents of the objects folder > (src/objects or whatever). I think I've found it.. The OSX Vim is built with FEAT_GUI_MAC always defined. This in turn forces FEAT_GUI to be defined. This is from around lines 66-102 of src/vim.h. In src/syntax.c:do_highlight() there are checks for FEAT_GUI to be defined. Items like "guifg" and "guibg" etc are conditionally compiled to only take effect if FEAT_GUI is defined (which it is in the OSX case). The call chain eventually looks like: do_highlight() color_name2handle() gui_get_color()<- E254: Cannot allocate color So because FEAT_GUI is always defined on OSX, vim gets these errors for console vim. I still don't quite understand why this is causing an error when it doesn't on linux. The console linux version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 8 2007 00:27:42) Included patches: 1 Huge version with GTK2 GUI. Features included (+) or not (-): ... While the console OSX version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 9 2007 11:33:38) MacOS X (unix) version Included patches: 1 Huge version with Carbon GUI. Features included (+) or not (-): ... So both have the GUI built in yet only the OSX version complains about the colour scheme being set.
Re: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: Hello vimmers, I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... Other colour schemes produce similar output. The error messages have only appeared for me in console vim on OSX (10.4.9 PPC). They have not appeared in the linux or win32 console vims of 7.1a.001. GVim's on each of the platforms (OSX, linux, Win32) have worked fine. My console vim is symlinked as follows: $ ls -l `which vim` lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim -> /Applications/Vim.app/Contents/MacOS/Vim These errors did not occur before 7.1a.001 and occurs on builds from CVS and SVN. The errors still occur even with starting vim with: vim -u NONE Has anyone else noticed this? These color names should be used only in the GUI. In the "desert" colorscheme I have (v1.1, 2004/06/13 19:30:30) they are only present in "guibg=" and "guifg=" arguments to the ":hi" command, which is normal. If you want to debug that problem, you may want to vimgrep your sources for the "highlight" command, then inspect the source to see if (as it should) it does ignore guibg= guifg= and gui= when setting highlights in Console Vim. You may restrict yourself to the modules which were actually compiled for your configure options, as shown e.g. by the contents of the objects folder (src/objects or whatever). Best regards, Tony. -- If all be true that I do think, There be Five Reasons why one should Drink; Good friends, good wine, or being dry, Or lest we should be by-and-by, Or any other reason why.
7.1a.001 OSX colour scheme errors?
Hello vimmers, I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... Other colour schemes produce similar output. The error messages have only appeared for me in console vim on OSX (10.4.9 PPC). They have not appeared in the linux or win32 console vims of 7.1a.001. GVim's on each of the platforms (OSX, linux, Win32) have worked fine. My console vim is symlinked as follows: $ ls -l `which vim` lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim -> /Applications/Vim.app/Contents/MacOS/Vim These errors did not occur before 7.1a.001 and occurs on builds from CVS and SVN. The errors still occur even with starting vim with: vim -u NONE Has anyone else noticed this?