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

73445Re: [patch] colorscheme autocommand should match against the colorscheme name

Expand Messages
  • Tony Mechelynck
    Sep 29, 2013
      On 28/09/13 16:12, Bram Moolenaar wrote:
      > Christian Brabandt wrote:
      >> currently, the colorscheme autocommand matches the pattern against the
      >> buffer name. I think, it would be more useful, to have the pattern match
      >> against the actual colorscheme name. So here is a patch, that changes
      >> it.
      > I suppose the ColorScheme event is most useful to make highlight changes
      > after loading a color scheme. This depends on the color scheme, but
      > may also depend on the syntax.
      > This change is not backwards compatible, does that matter?
      > What are people actually using the ColorScheme event for?
      I use it in my "almost-default" colorscheme to detect that another
      colorscheme is being loaded, in order to unset autocommands which were
      set (with a group name equal to my autocommand name) when sourcing mine.
      (I change the statusbar colour at CursorHold and CursorHoldI; of course
      this mustn't continue after my colorscheme has been replaced by another

      The CSApprox plugin uses it to interpret GUI highlights defined by the
      new colorscheme and set new cterm highlights approximating them, when
      run in Console mode in an 88- or 256-color terminal. It does the same at
      startup without an autocommand, if a colorscheme has already be loaded
      (e.g. by the vimrc).

      In both cases above, matching is on * (i.e. anything).

      In any case, since this autocommand event is triggered _after_ loading a
      colorscheme, the g:colors_name variable ought to contain the new
      colorscheme's name. So autocommand handlers which need to check the
      autocommand name don't need it in <amatch>: they can already use

      au ColorScheme * if g:colors_name ==

      etc.; mine does. OTOH highlights set by a colorscheme are supposed to be
      global, so the buffer name is of little use at this event. (However, who

      The compatibility problem that I can see is: how will ColorScheme
      observers know that they can afford to match on the colorscheme name?
      IMHO it will be simpler to go on testing g:colors_name (for
      compatibility) even if the latest patchlevel is known to include the change.

      Best regards,
      America, how can I write a holy litany in your silly mood?
      -- Allen Ginsberg

      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

      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Show all 5 messages in this topic