73445Re: [patch] colorscheme autocommand should match against the colorscheme name
- Sep 29, 2013On 28/09/13 16:12, Bram Moolenaar wrote:
>I use it in my "almost-default" colorscheme to detect that another
> 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
> 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?
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.
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.
- << Previous post in topic