[Question] Why does :autocmd trigger modeline processing?

186 views
Skip to first unread message

Kana Natsuno

unread,
Nov 7, 2011, 7:28:05 PM11/7/11
to vim_dev
From :help :doautocmd in Vim 7.3.353:

> *:do* *:doau* *:doautocmd* *E217*
> :do[autocmd] [group] {event} [fname]
> Apply the autocommands matching [fname] (default:
> current file name) for {event} to the current buffer.
> You can use this when the current file name does not
> match the right pattern, after changing settings, or
> to execute autocommands for a certain event.
> It's possible to use this inside an autocommand too,
> so you can base the autocommands for one extension on
> another extension. Example: >
> :au Bufenter *.cpp so ~/.vimrc_cpp
> :au Bufenter *.cpp doau BufEnter x.c
> < Be careful to avoid endless loops. See
> |autocmd-nested|.
>
> When the [group] argument is not given, Vim executes
> the autocommands for all groups. When the [group]
> argument is included, Vim executes only the matching
> autocommands for that group. Note: if you use an
> undefined group name, Vim gives you an error message.
>
> After applying the autocommands the modelines are
> processed, so that their settings overrule the
> settings from autocommands, like what happens when
> editing a file.

I wonder about the last paragraph. There is not any condition to
process modelines by :doautocmd. It means that :doautocmd triggers
modeline processing in any context.

For example, I have something like the following in my vimrc to
indicate
the same code will be run at both CursorHold and CursorHoldI events:

augroup MyConfig
autocmd CursorHold * call s:save_stat()
autocmd CursorHoldI * doautocmd MyConfig CursorHold
augroup END

Suppose that the current buffer contains some modelines. Modelines
will
be processed for each time whenever CursorHoldI is happened, even if
the
file is already loaded. Moreover, running :doautocmd like ":doautocmd
User foo" by hand also triggers modeline processing.

The current behavior seems to be odd, and it causes side effects at
unexpected timing depending on user's configuration. I think that
modelines should be processed while opening a file and it should not
be
processed other timing.

Is the current behavior intended one? If so, what is the reason?

Ingo Karkat

unread,
Nov 8, 2011, 2:45:57 AM11/8/11
to vim...@googlegroups.com
On 08-Nov-2011 01:28, Kana Natsuno wrote:

> [...]


>
> It means that :doautocmd triggers modeline processing in any context.

I have occasionally used :doautocmd, but that didn't cause any problems for me.
I do share your concerns, a clear separation (e.g. :domodelines) or at least
good explanation would be appreciated.

> For example, I have something like the following in my vimrc to
> indicate
> the same code will be run at both CursorHold and CursorHoldI events:
>
> augroup MyConfig
> autocmd CursorHold * call s:save_stat()
> autocmd CursorHoldI * doautocmd MyConfig CursorHold
> augroup END

You can group events, this makes it even clearer, and no need for :doautocmd:
augroup MyConfig
autocmd CursorHold,CursorHoldI * call s:save_stat()
augroup END

-- regards, ingo

Kana Natsuno

unread,
Nov 11, 2011, 6:50:10 AM11/11/11
to vim...@googlegroups.com
On Tue, Nov 8, 2011 at 4:45 PM, Ingo Karkat <sw...@ingo-karkat.de> wrote:
> You can group events, this makes it even clearer, and no need for :doautocmd:
>     augroup MyConfig
>       autocmd CursorHold,CursorHoldI *  call s:save_stat()
>     augroup END

Ah, I forgot about that syntax of :autocmd.
Thank you for the tip.

Bram Moolenaar

unread,
Nov 27, 2011, 2:40:26 PM11/27/11
to Kana Natsuno, vim_dev

Kana Natsuno wrote:

The original idea of this command was to execute autocommands for
loading the buffer. So that you can trigger the right autocommands if
the file type wasn't detected.

It would make sense to only trigger modelines when executing the
autocommands that are used when loading a buffer. That might be
complicated though. Alternatively we could add an argument to the
command to skip processing modelines. We could use the [!] flag,
although it might be a bit strange to have this effect.
Perhaps a <nomodeline> argument?

--
What is the difference between a professional and an amateur?
The ark was built by an amateur; professionals gave us the Titanic.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Kana Natsuno

unread,
Nov 28, 2011, 6:07:56 AM11/28/11
to Bram Moolenaar, vim...@googlegroups.com
On Mon, Nov 28, 2011 at 4:40 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Kana Natsuno wrote:
>
>> >From :help :doautocmd in Vim 7.3.353:
>>
>> >                                         *:do* *:doau* *:doautocmd* *E217*
>> > :do[autocmd] [group] {event} [fname]
>> >
>> > [...]

>> >
>> >                         After applying the autocommands the modelines are
>> >                         processed, so that their settings overrule the
>> >                         settings from autocommands, like what happens when
>> >                         editing a file.
>>
>> [...]

>>
>> The current behavior seems to be odd, and it causes side effects at
>> unexpected timing depending on user's configuration.  I think that
>> modelines should be processed while opening a file and it should not
>> be
>> processed other timing.
>>
>> Is the current behavior intended one?  If so, what is the reason?
>
> The original idea of this command was to execute autocommands for
> loading the buffer.  So that you can trigger the right autocommands if
> the file type wasn't detected.

Thank you for the reply. I understand the original intention about
triggering modelines.


> It would make sense to only trigger modelines when executing the
> autocommands that are used when loading a buffer.  That might be
> complicated though.  Alternatively we could add an argument to the
> command to skip processing modelines.  We could use the [!] flag,
> although it might be a bit strange to have this effect.
> Perhaps a <nomodeline> argument?

I prefer <nomodeline> to the others. It is less complicated than the
others, and it is backward compatible for existing scripts. I'll try to
make a patch.

Reply all
Reply to author
Forward
0 new messages