Loading ...
Sorry, an error occurred while loading the content.

Re: 7.1a.001 OSX colour scheme errors?

Expand Messages
  • A.J.Mechelynck
    ... 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
    Message 1 of 12 , May 8, 2007
    • 0 Attachment
      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.
    • Michael Wookey
      ... from ... have ... sources ... 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.
      Message 2 of 12 , May 8, 2007
      • 0 Attachment
        > 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.
      • A.J.Mechelynck
        ... 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
        Message 3 of 12 , May 9, 2007
        • 0 Attachment
          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.
        • Michael Wookey
          ... 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
          Message 4 of 12 , May 9, 2007
          • 0 Attachment
            > 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!
          • A.J.Mechelynck
            ... 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
            Message 5 of 12 , May 9, 2007
            • 0 Attachment
              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!
            • Michael Wookey
              ... on ... 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
              Message 6 of 12 , May 9, 2007
              • 0 Attachment
                > 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.
              • Bram Moolenaar
                ... 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,
                Message 7 of 12 , May 9, 2007
                • 0 Attachment
                  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":
                  :-X My lips are sealed

                  /// Bram Moolenaar -- Bram@... -- 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 ///
                • Michael Wookey
                  ... 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
                  Message 8 of 12 , May 9, 2007
                  • 0 Attachment
                    > > 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.
                  • Bram Moolenaar
                    ... 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.
                    Message 9 of 12 , May 10, 2007
                    • 0 Attachment
                      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 -- Bram@... -- 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 ///
                    • A.J.Mechelynck
                      Bram Moolenaar wrote: [...] ... Just for the record, after reformatting the entries to a common format and sorting, a diff between my
                      Message 10 of 12 , May 10, 2007
                      • 0 Attachment
                        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.
                      • Bram Moolenaar
                        ... Unless someone has an enhanced rgb.txt... ... Looks good. But I ll include it later. Needs some testing first. -- ... /// Bram Moolenaar --
                        Message 11 of 12 , May 10, 2007
                        • 0 Attachment
                          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":
                          :-E Has major dental problems

                          /// Bram Moolenaar -- Bram@... -- 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 ///
                        Your message has been successfully submitted and would be delivered to recipients shortly.