[vim/vim] Autocmd ColorScheme * no longer works. (#7940)

[David le Blanc]

Describe the bug
The command

autocmd ColorScheme * setlocal et

Fails with

E1155: Cannot define autocommands for ALL events

To Reproduce
Detailed steps to reproduce the behavior:

1. Build any release of VIM from v8.2.2420 onwards. (v8.2.2420 with found with git-bisect, though the comment text was obvious in hindsight)
2. Launch vim.
3. Enter the command :autocmd ColorScheme * setlocal et
   Expected behavior
   No error. et flag will get set on color scheme changes.

Note that "forcing" the command with

autocmd! ColorScheme * setlocal et

Does not display an error, but also does not appear to work.

Note: Choice of command to run (eg setlocal et) is irrelevant.

Environment (please complete the following information):

• Vim version 8.2.2420 to 8.2.2580
• OS: Ubuntu 20.04
• Terminal: putty/ssh

Additional context
Add any other context about the problem here.

As a side effect, this break vim-gitgutter and vim-airline plugins.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Maxim Kim]

Can't reproduce with the latest master.

Could you try it with vim -Nu NONE?

[Bram Moolenaar]

You probably have a group with the name colorscheme. Try ":augroup".
Having a group name equal to an event name is likely to cause trouble like this.

[David le Blanc]

You probably have a group with the name colorscheme. Try ":augroup".

Thanks for that. Renaming a group solved the issue. My apologies for the noise.

Is there a use for a group with the same name as an event? The manual for augroup is a bit vague.

[David le Blanc]

Closed #7940.

[Tony Mechelynck]

AFAIK, using a group with the same name as one of the built-in event names is looking for trouble. When you invent a group name for use in one of your scripts, try to choose something distinctive enough not to clash, not only with any existing event name, but also with any event name that Bram might invent in the future. This may require imagination. ;-)

[Bram Moolenaar]

Perhaps we should disallow using a group name that matches an event name? That might cause trouble when adding new events though. Considering that having this problem is rare, it's probably better to leave it as it is.

[Dominique Pellé]

How about having vim syntax highlighting of :augroup {name} highlight the name as an error if it matches an event name. At least it can help to spot such problematic case.

[David le Blanc]

I would chalk it up to user error. The manual does imply things break if you do what I did, and TBH I actually had a group called 'Colorscheme' which originally did not conflict because group names are case sensitive, while autocommand names are not.

The difference in case handling between the group name and the event name can result in interesting behaviours..

autocmd colorscheme * echo 'done'    <- works because event names are not case sensitive

augroup colorscheme
     autocmd ColorScheme * echo 'done'  <- also works.
     autocmd colorscheme * echo 'done'  <- no longer works because 'colorscheme' matches the group name.

conversely

augroup ColorScheme
     autocmd colorscheme * echo 'done'

also works fine....But don't do that.

As an alternative workaround, can I suggest that in autocmd [group] [event] {pat}, the first parameter is checked against the eventlist, then on no-match, check if it matches a group name. This would make the error more meaningful and still catch au <groupname> * problems.

augroup ColorScheme
     au ColorScheme * echo

would work with the change, without triggering the original problem, or breaking things (afaict).