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

Re: Patch to allow ctermfg or bg values as #rrggbb

Expand Messages
  • Neil Moore
    ... It works well for me (after editing my system colorschemes). A few things I noticed: * The new code be wrapped in an #ifdef FEAT_SYN_HL . Certain of the
    Message 1 of 33 , Mar 1, 2008
    • 0 Attachment
      On Jan 3, 4:30 pm, "Matt Wozniski" <m...@...> wrote:
      > On Dec 20, 2007 11:44 PM, Matt Wozniski <m...@...> wrote:
      >
      >
      >
      > > ...
      > > So, I've reworked the patch to support, in addition to the
      > > xterm-compatible palette, Eterm and Konsole's palettes. Which palette
      > > is used for the matching is controlled by a new option, 'termpalette'
      > > (short name 'tpal'). If the option is unset, I default to an xterm
      > > palette, but display a warning that color matching might be
      > > unaccurate.
      >
      > > For those interested, a comparison between the 3 palettes that I've
      > > found so far can be seen here:
      > >http://www.cs.drexel.edu/~mjw452/256.html
      >
      > > So, I'd appreciate comments. The reworked patch can be found:
      > >http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff(source, against SVN)
      > >http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff(runtime,
      > > against latest AAP)
      >
      > > And, the two modified colorschemes for testing are available at
      > >http://www.cs.drexel.edu/~mjw452/brookstream-rgb.vimand
      > >http://www.cs.drexel.edu/~mjw452/autumnleaf-rgb.vim; it should be
      > > trivial to modify other colorschemes in this way.
      >
      > > Please comment!
      > > ~Matt
      >
      > Has anyone tried this out? I would love to have some feedback on
      > this, since I think that it would be a really nice feature to make
      > life easier for colorscheme authors!
      >
      > ~Matt

      It works well for me (after editing my system colorschemes). A few
      things I noticed:

      * The new code be wrapped in an #ifdef FEAT_SYN_HL . Certain of the
      prototypes are, which means the code doesn't compile correctly when
      this feature is disabled.
      * hexhex2nr in charset.c should be defined whenever the patch is
      included (as noted in a comment). Adding defined(FEAT_SYN_HL) to the
      list of conditions should work.

      * As discussed on IRC, colorschemes will have to define colors
      differently depending on whether one is in 16- or 256-color mode. If
      hex colors aren't going to be supported for 16-color mode (and I think
      your arguments here are convincing), maybe there should be separate
      hctermfg/hctermbg arguments for high-color schemes. This would
      require less work on the part of colorscheme authors to support both
      kinds of terminals (they could keep ctermfg=14 and add a separate
      hctermfg=#ff33ff to support high-color terms).

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Ingo Karkat
      ... If you don t change your colorscheme often, CSApprox.vim (again, thanks Matt for this wonderful plugin!) allows to take a static snapshot, which avoids the
      Message 33 of 33 , Jul 24, 2010
      • 0 Attachment
        On 21-Jul-2010 20:57, Matt Wozniski wrote:
        > The down side is that it's a bit slow (as Dominique pointed out), but
        > I have a version in my sandbox that should hopefully help a bit with
        > that.

        If you don't change your colorscheme often, CSApprox.vim (again, thanks Matt for
        this wonderful plugin!) allows to take a static snapshot, which avoids the
        runtime penalty of translating all colors on each Vim launch; instead, only the
        generated snapshot is sourced.

        I have my own colorscheme, and here's how I generate a new snapshot whenever I
        have modified it (notice how I have put CSApprox in .vim/, not .vim/plugin/, so
        it's only sourced on-demand for this one-time conversion):

        gvim -c "runtime CSApprox.vim|CSApproxSnapshot!
        ~/.vim/colors/ingo-cterm.vim|quit"

        In my .vimrc, the following fragment detects a color terminal and then sources
        the snapshot. (Though this isn't strictly necessary, it falls back to the
        original, handwritten colorscheme when run in a plain terminal or the GUI.)

        let g:color_terminal = ! has('gui_running') && &t_Co >= 88
        if g:color_terminal
        " There may exist a high color snapshot of my colorscheme generated by
        " CSApprox.vim.
        try
        colorscheme ingo-cterm
        catch /^Vim\%((\a\+)\)\=:E185/ " catch error E185: Cannot find color scheme
        colorscheme ingo
        endtry
        else
        colorscheme ingo
        endif

        This works well for me, so I would recommend such an approach to try in case
        you're concerned about the startup performance.

        -- regards, ingo
        --
        -- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
        -- http://vim.sourceforge.net/account/profile.php?user_id=9713 --

        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      Your message has been successfully submitted and would be delivered to recipients shortly.