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

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

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