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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.