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

Re: How to solve: E254: Cannot allocate color darkyellow

Expand Messages
  • Eric Arnold
    It s not clear if you tried: hi def darkyellow guifg=#BBBB00 darkyellow is not a default color for me (MSwinXP) also. darkyellow is defined as a keyword
    Message 1 of 11 , Jun 6, 2005
    • 0 Attachment
      It's not clear if you tried:

      hi def darkyellow guifg=#BBBB00

      "darkyellow" is not a default color for me (MSwinXP) also. "darkyellow"
      is defined as a keyword in "vim.vim" and many other files, but I couldn't
      find the basic definition by doing a 'grep -Rin darkyellow .' in
      my vim63 directory. I'm wondering if it used to be a default color and
      got lost somewhere in some release.

      However I have no problem creating it. If you simply want the color for
      your own self, you can put it in the bottom of your .gvimrc as

      autocmd GUIEnter * hi def darkyellow guifg=#BBBB00

      Having it as a autocmd might be overkill, but it was the only way I was
      able to override the colors in my colorscheme in my .gvimrc or .vimrc
      and have the change stick.

      If :echo g:colors_name shows nothing or is undefined for you (meaning
      "colorscheme" is really not in effect), and you want to make a darkyellow
      that works for other users as well, it might be worth making your own
      colorscheme file with darkyellow in it, but you'd have to change
      everybody's .gvimrc so use it, so it's hard to say if it is worth it for
      just a color or two.

      Another way to do it without changing anyone's .*vimrc files, and I
      don't know if this is the correct way to do it or not, would be to put a
      version of the syncolor.vim file (because it is one of the files called
      in the default start up) in your $HOME/.vim/after/syntax
      directory ( or $HOME/vimfiles/after/syntax etc.) with the single line:

      hi def darkyellow guifg=#BBBB00

      This works for me if I put it in my $HOME/vimfiles/after/syntax directory,
      but it is supposed to also work in $VIM/after/syntax which should
      define the color for other users also, but I can't get that to work. I'm
      just inferring what the directory should be from the help entry:

      *after-directory*
      4. In the "after" directory in the system-wide Vim directory. This is
      for the system administrator to overrule or add to the distributed
      defaults (rarely needed)
      5. In the "after" directory in your home directory. This is for
      personal preferences to overrule or add to the distributed defaults
      or system-wide settings (rarely needed).


      So, #5 works but #4 has me stumped.



      --- Alan Schmitt <alan.schmitt@...> wrote:

      > Le 6 juin 05, à 12:22, Bram Moolenaar a écrit :
      >
      > >
      > > Alan Schmitt wrote:
      > >
      > >> I've been having this problem for a while, and I would like to solve
      > >> it. Using some syntax hilighters, I keep getting the error: E254:
      > >> Cannot allocate color darkyellow
      > >>
      > >> I looked at the help for that error, but I could not find how to solve
      > >> it. Any suggestion? I'm using ViM 6.3 for OS X (gvim version). The
      > >> strange thing is that everything works when I use vim in the terminal,
      > >> and not gvim.
      > >
      > > The problem is that the GUI doesn't know the color DarkYellow, although
      > > it should (it's a standard color).
      > >
      > > If you have a ":colorscheme" command, avoid it, or if you see the
      > > DarkYellow color used somewhere replace it with "#BBBB00".
      >
      > Thanks for the suggestion. I'm not using any colorscheme, and I tried
      > switching them but it changed nothing.
      >
      > I'm copying the vim-mac mailing list in case someone has already seen
      > this.
      >
      > Alan
      >
    • A. J. Mechelynck
      ... [...] The way I understand it, the above would defined the _highlight group_ darkyellow with fg=#BBBB00 as its default colour. You cannot use that where
      Message 2 of 11 , Jun 6, 2005
      • 0 Attachment
        Eric Arnold wrote:
        >
        > It's not clear if you tried:
        >
        > hi def darkyellow guifg=#BBBB00
        >
        [...]

        The way I understand it, the above would defined the _highlight group_
        darkyellow with fg=#BBBB00 as its default colour. You cannot use that
        where you would a _color name_, any more that you can use "guifg=Error"
        or "guifg=NonText". You have to replace the offending "guifg=darkyellow"
        or "guibg=darkyellow" clause. See my post of a few minutes ago.


        Best regards,
        Tony.
      • Eric Arnold
        Note to Alan. Your original message didn t say exactly how you were trying to use darkyellow . ... As it turns out, it is a color, not a color group ( group
        Message 3 of 11 , Jun 6, 2005
        • 0 Attachment
          Note to Alan. Your original message didn't say exactly how you were
          trying to use "darkyellow".

          >> I've been having this problem for a while, and I would like to solve
          >> it. Using some syntax hilighters, I keep getting the error: E254:
          >> Cannot allocate color darkyellow

          As it turns out, it is a color, not a color group ("group" is misleading
          IMHO), so you can only use it after "guifg=" or "guibg=", etc. not for
          commands like "match". If you want that, you can define a color group of
          the same name, as long as you don't let it confuse things more. I.e.:

          match darkyellow /pattern/

          fails, but

          hi darkyellow guifg=darkyellow
          match darkyellow /pattern/

          works.

          If it turns out that "darkyellow" really isn't defined as a core color
          on your system, and it has somewhere been defined as a color group,
          this results in the same error as for non-existent colors when trying
          to use it as a color in "guifg=", etc.,

          E254 cannot allocate color [some color group name]

          which is the error that matches the one you first posted about.


          --- "A. J. Mechelynck" <antoine.mechelynck@...> wrote:


          > Eric Arnold wrote:
          > >
          > > It's not clear if you tried:
          > >
          > > hi def darkyellow guifg=#BBBB00
          > >
          > [...]
          >
          > The way I understand it, the above would defined the _highlight group_
          > darkyellow with fg=#BBBB00 as its default colour. You cannot use that
          > where you would a _color name_, any more that you can use "guifg=Error"
          > or "guifg=NonText". You have to replace the offending "guifg=darkyellow"
          > or "guibg=darkyellow" clause. See my post of a few minutes ago.


          Hmm. It actually worked, sorta, kinda. I think this is because
          "darkyellow" is defined more deeply in Vim, so although I [re]defined it as a
          group, I didn't change it's ability to be used as a color in guifg= ,
          which is what tripped me up when I tested it for my last message.
          Apparently, colors and color groups have different name spaces.

          Also, :hi def .. or :highlight default ... isn't actually desirable
          here, since we *do* want to override a default rather than set one. As
          explained by :h hi-default , the "def" simply seems to be a way to
          control what overrides what. So I guess I was wrong on multiple accounts.

          The big mystery for me though, the difference between colors and color groups.
          This is why "darkyellow" as delivered with vim63, is usable (for me) as a
          color in guifg=darkyellow but not as a group for the "match" command,
          until I [accidentally] defined a group of the same name. Another test that
          seems obvious that basic colors are different from groups,

          :hi darkyellow
          returns
          E411: highlight group not found

          I'm still trying to understand how to define a color which is not a group.
          Since "grep" didn't show me anything in the "syntax" or "colors"
          directories, I'm assuming it's defined deeper in the Vim structure. The
          doc.s all seem to point to "syntax.txt", which tells us "highlight" is
          the way to create colors, but only color groups. Is there a help entry
          on the difference? (I found only the entries on what colors were available
          for different GUI and terminal types, but not how to define your own.)
          I'm suspecting that it isn't possible, or else there wouldn't be so many
          #HEXHEXHEX defines where color names would be more readable.
        • A. J. Mechelynck
          ... Oy yeah? I would expect the same error on the hi line as that noticed by the OP (i.e., E254) ... Highlight group names are defined either by Vim itself
          Message 4 of 11 , Jun 7, 2005
          • 0 Attachment
            Eric Arnold wrote:
            > Note to Alan. Your original message didn't say exactly how you were
            > trying to use "darkyellow".
            >
            >
            >>>I've been having this problem for a while, and I would like to solve
            >>>it. Using some syntax hilighters, I keep getting the error: E254:
            >>>Cannot allocate color darkyellow
            >
            >
            > As it turns out, it is a color, not a color group ("group" is misleading
            > IMHO), so you can only use it after "guifg=" or "guibg=", etc. not for
            > commands like "match". If you want that, you can define a color group of
            > the same name, as long as you don't let it confuse things more. I.e.:
            >
            > match darkyellow /pattern/
            >
            > fails, but
            >
            > hi darkyellow guifg=darkyellow
            > match darkyellow /pattern/
            >
            > works.

            Oy yeah? I would expect the same error on the "hi" line as that noticed
            by the OP (i.e., E254)

            > [...] The big mystery for me though, the difference between colors and color groups.
            > This is why "darkyellow" as delivered with vim63, is usable (for me) as a
            > color in guifg=darkyellow but not as a group for the "match" command,
            > until I [accidentally] defined a group of the same name. Another test that
            > seems obvious that basic colors are different from groups,
            >
            > :hi darkyellow
            > returns
            > E411: highlight group not found
            >
            > I'm still trying to understand how to define a color which is not a group.
            > Since "grep" didn't show me anything in the "syntax" or "colors"
            > directories, I'm assuming it's defined deeper in the Vim structure. The
            > doc.s all seem to point to "syntax.txt", which tells us "highlight" is
            > the way to create colors, but only color groups. Is there a help entry
            > on the difference? (I found only the entries on what colors were available
            > for different GUI and terminal types, but not how to define your own.)
            > I'm suspecting that it isn't possible, or else there wouldn't be so many
            > #HEXHEXHEX defines where color names would be more readable.


            Highlight "group" names are defined either by Vim itself (see the
            'highlight' option) or by syntax scripts (as syntax groups). There is a
            limit (a high one) on the maximum number of different highlight groups
            which can be defined in a running instance of Vim; I don't know what it is.


            Color names can be either symbolic (see below) or numeric (in the form
            #RRGGBB, in hex).

            Color values in the form #RRGGBB can be used anywhere in guifg= or guibg=

            Symbolic color names can also be used, provided that they are defined on
            your system, see ":help rgb.txt". $VIMRUNTIME/rgb.txt defines the
            default set. The help text says that "it must be located in
            $VIMRUNTIME", which implicitly means that you cannot change it. I don't
            know if (or why not) it can reside also in any other directory in
            'runtimepath' or whether additions to it may or may not be done by means
            of a file named, let's say, $VIM/vimfiles/after/rgb.txt


            Best regards,
            Tony.
          • Eric Arnold
            ... I was a little surprised when it worked, but since it appears that the name spaces are independent, there s nothing to keep you from doing it. It still
            Message 5 of 11 , Jun 7, 2005
            • 0 Attachment
              --- "A. J. Mechelynck" <antoine.mechelynck@...> wrote:
              > Eric Arnold wrote:
              ...
              > >
              > > As it turns out, it is a color, not a color group ("group" is misleading
              > > IMHO), so you can only use it after "guifg=" or "guibg=", etc. not for
              > > commands like "match". If you want that, you can define a color group of
              > > the same name, as long as you don't let it confuse things more. I.e.:
              > >
              > > match darkyellow /pattern/
              > >
              > > fails, but
              > >
              > > hi darkyellow guifg=darkyellow
              > > match darkyellow /pattern/
              > >
              > > works.
              >
              > Oy yeah? I would expect the same error on the "hi" line as that noticed
              > by the OP (i.e., E254)

              I was a little surprised when it worked, but since it appears that the name
              spaces are independent, there's nothing to keep you from doing it. It
              still might not work for the original poster, if "darkyellow" isn't defined
              as a color ("darkyellow" isn't in "rgb.txt", but there are 6 different
              light yellows. Hmm, how many light yellows does it take to make a dark
              yellow? ).

              >
              ...
              > Symbolic color names can also be used, provided that they are defined on
              > your system, see ":help rgb.txt". $VIMRUNTIME/rgb.txt defines the
              > default set. The help text says that "it must be located in
              > $VIMRUNTIME", which implicitly means that you cannot change it. I don't
              > know if (or why not) it can reside also in any other directory in
              > 'runtimepath' or whether additions to it may or may not be done by means
              > of a file named, let's say, $VIM/vimfiles/after/rgb.txt

              The good news is that "rgb.txt" is monitored at run time, so it picks
              up changes to "rgb.txt" as soon as you make them (without restarting
              Vim). The bad news that adding another "rgb.txt" to $VIM/vimfiles or
              $VIM/vimfiles/after doesn't seem to work.

              Anyway, adding the equivalent of #BBBB00,
              187 187 0 darkyellow
              to "rgb.txt" is another thing for Alan to try, after
              hi test guifg=darkyellow
              to be sure you get the E254 not found error.
            • A. J. Mechelynck
              Eric Arnold wrote: [...] ... My rgb.txt doesn t include darkyellow , nor is that name listed in a list of symbolic color name which I found in an appendix to
              Message 6 of 11 , Jun 7, 2005
              • 0 Attachment
                Eric Arnold wrote:
                [...]
                > Anyway, adding the equivalent of #BBBB00,
                > 187 187 0 darkyellow
                > to "rgb.txt" is another thing for Alan to try, after
                > hi test guifg=darkyellow
                > to be sure you get the E254 not found error.
                >
                >
                >
                >

                My rgb.txt doesn't include "darkyellow", nor is that name listed in a
                list of symbolic color name which I found in an appendix to a book over
                HTML. It lists the colors in lexicographic order on the RRGGBB value.
                I'm not listing the whole long list, but here are the names for colors
                whose red component is in the range B0-BF:

                #B0C4DE Lightsteelblue
                #B0E0E6 Powderblue
                #B22222 Firebrick
                #B8860B Darkgoldenrod
                #BA55D3 Mediumorchid
                #BC8F8F Rosybrown
                #BDB76B Darkkhaki

                IIUC, "darkyellow" is not a standard symbolic colour name. For
                portability, I would suggest to replace it (after guifg= or guibg=)
                either by a numeric value such as #BBBB00, or by a "standard" symbolic
                name; here are a few examples:

                #A52A2A Brown
                #808000 Olive (not in my rgb.txt)
                #FFFF00 Yellow


                Best regards,
                Tony.
              • Alan Schmitt
                ... First of all, thanks a lot to Eric and Antoine for this enlightening discussion. Some of it went way over my head, but I was able to solve the problem. As
                Message 7 of 11 , Jun 7, 2005
                • 0 Attachment
                  Le 7 juin 05, à 06:39, Eric Arnold a écrit :

                  > --- "A. J. Mechelynck" <antoine.mechelynck@...> wrote:
                  >
                  >> Symbolic color names can also be used, provided that they are defined
                  >> on
                  >> your system, see ":help rgb.txt". $VIMRUNTIME/rgb.txt defines the
                  >> default set. The help text says that "it must be located in
                  >> $VIMRUNTIME", which implicitly means that you cannot change it. I
                  >> don't
                  >> know if (or why not) it can reside also in any other directory in
                  >> 'runtimepath' or whether additions to it may or may not be done by
                  >> means
                  >> of a file named, let's say, $VIM/vimfiles/after/rgb.txt
                  >
                  > The good news is that "rgb.txt" is monitored at run time, so it picks
                  > up changes to "rgb.txt" as soon as you make them (without restarting
                  > Vim). The bad news that adding another "rgb.txt" to $VIM/vimfiles or
                  > $VIM/vimfiles/after doesn't seem to work.
                  >
                  > Anyway, adding the equivalent of #BBBB00,
                  > 187 187 0 darkyellow
                  > to "rgb.txt" is another thing for Alan to try, after
                  > hi test guifg=darkyellow
                  > to be sure you get the E254 not found error.

                  First of all, thanks a lot to Eric and Antoine for this enlightening
                  discussion. Some of it went way over my head, but I was able to solve
                  the problem.

                  As I'm using the default colorscheme, I did not really know what to do
                  (and where to copy it from). I also had no g:colors_name defined.

                  So I edited $VIMRUNTIME/rgb.txt and added the line suggested above, and
                  everything is working now. It bothers me a little to have to edit vim
                  runtime files directly, but I'll know what to do next time I upgrade my
                  Vim.

                  Thanks again to everyone,

                  Alan
                • Alan Schmitt
                  ... The problem is that I do not know where this darkyellow comes from. I have the error when I edit otl files (vimoutliner files) and ml files using the
                  Message 8 of 11 , Jun 7, 2005
                  • 0 Attachment
                    Le 7 juin 05, à 07:16, A. J. Mechelynck a écrit :

                    > IIUC, "darkyellow" is not a standard symbolic colour name. For
                    > portability, I would suggest to replace it (after guifg= or guibg=)
                    > either by a numeric value such as #BBBB00, or by a "standard" symbolic
                    > name; here are a few examples:
                    >
                    > #A52A2A Brown
                    > #808000 Olive (not in my rgb.txt)
                    > #FFFF00 Yellow

                    The problem is that I do not know where this "darkyellow" comes from. I
                    have the error when I edit otl files (vimoutliner files) and ml files
                    using the omlet filetype. I guess these syntax hilighters are using
                    this colour.

                    Alan
                  • A. J. Mechelynck
                    Alan Schmitt wrote: [...] ... If you have no colorscheme defined, you must have one or more :hi[ghlight] statements somewhere, probably in your vimrc but
                    Message 9 of 11 , Jun 7, 2005
                    • 0 Attachment
                      Alan Schmitt wrote:
                      [...]
                      > First of all, thanks a lot to Eric and Antoine for this enlightening
                      > discussion. Some of it went way over my head, but I was able to solve
                      > the problem.
                      >
                      > As I'm using the default colorscheme, I did not really know what to do
                      > (and where to copy it from). I also had no g:colors_name defined.
                      >
                      > So I edited $VIMRUNTIME/rgb.txt and added the line suggested above, and
                      > everything is working now. It bothers me a little to have to edit vim
                      > runtime files directly, but I'll know what to do next time I upgrade my
                      > Vim.
                      >
                      > Thanks again to everyone,
                      >
                      > Alan

                      If you have no colorscheme defined, you must have one or more
                      ":hi[ghlight]" statements somewhere, probably in your vimrc but maybe
                      elsewhere. If it bothers you (as it bothers me) to edit distribution
                      files, you may want to search your vimrc (and any scripts sourced from
                      it) for the pattern /\c\<darkyellow\>/ . You might even try

                      :1,$s/\c\(gui.g=\)darkyellow\>/\1#BBBB00/g

                      Add a c at the very end if you want to "confirm" every substitution.


                      Or else (a trick mentioned at ":help fvwm.vim", I *don't* know if it
                      works for non-Unix systems) you might move your rgb.txt elsewhere, let's
                      say in your home directory, and add

                      let rgb_file = $HOME . "/rgb.txt"

                      to your _vimrc.


                      Best regards,
                      Tony.
                    • A. J. Mechelynck
                      ... Well, it must come from some script that you sourced. All those scripts names are listed by the :scriptnames command. You may want to search scripts in
                      Message 10 of 11 , Jun 7, 2005
                      • 0 Attachment
                        Alan Schmitt wrote:
                        > Le 7 juin 05, à 07:16, A. J. Mechelynck a écrit :
                        >
                        >> IIUC, "darkyellow" is not a standard symbolic colour name. For
                        >> portability, I would suggest to replace it (after guifg= or guibg=)
                        >> either by a numeric value such as #BBBB00, or by a "standard" symbolic
                        >> name; here are a few examples:
                        >>
                        >> #A52A2A Brown
                        >> #808000 Olive (not in my rgb.txt)
                        >> #FFFF00 Yellow
                        >
                        >
                        > The problem is that I do not know where this "darkyellow" comes from. I
                        > have the error when I edit otl files (vimoutliner files) and ml files
                        > using the omlet filetype. I guess these syntax hilighters are using this
                        > colour.
                        >
                        > Alan

                        Well, it must come from some script that you sourced. All those scripts'
                        names are listed by the ":scriptnames" command. You may want to search
                        scripts in that list for /darkyellow/


                        Best regards,
                        Tony.
                      Your message has been successfully submitted and would be delivered to recipients shortly.