Autocommand event for new buffers including startup buffer
Taylor Hedberg
in each new buffer as it is opened. However, these events are not
triggered in the "No Name" buffer that is created when Vim is launched
without arguments.
In my .vimrc:
autocmd BufNewFile,BufRead * let b:foo = 1
If I launch Vim with `vim test.txt`, then b:foo is defined in the
resulting buffer. If I launch with just `vim`, however, it is undefined
in the "startup" buffer, but any subsequent buffers I create, say with
`:e`, do have b:foo defined.
Is there an autocommand event that applies to the default startup buffer
as well as all subsequently created buffers? Using something like
`BufNewFile,BufRead,VimEnter` doesn't work for me in this case, because
VimEnter triggers too late to be useful for the result I'm trying to
achieve. I need an event which occurs at the same time (or earlier) in
the buffer creation process as the other two.
Tony Mechelynck
Which effect do you try to achieve exactly? BufWinEnter is triggered
when newly loading a buffer (including the first buffer, even if it is a
[No Name] buffer), or when "unhiding" (into a window) a buffer which was
loaded but hidden (and not even displayed in a different window), but
from your description I can't tell with certainty if it's early enough
for you. In particular it happens (unlike BufRead) after processing
modelines and (I think) after the FileType event if the file has a
nonempty autodetected 'filetype'. Of course a [No Name] file never has a
'filetype' unless you set one yourself after opening the file.
After starting Vim as
vim --cmd 'au BufRead,BufNewFile * let b:foo = 1'
I never see b:foo defined in a [No Name] buffer, no matter if it is the
initial buffer, or a buffer created in a new window by :new, or in the
current window by :enew. :e (with no filename) doesn't work for me in a
[No Name] buffer, it gives me
E32: No file name
while in a named buffer it reloads the current file from disk, but only
if used with an exclamation mark or if 'autowriteall' is on; otherwise
it gives error "E37: No write since last change (add ! to override)"
(regardless of the status of 'hidden').
Best regards,
Tony.
--
How come wrong numbers are never busy?
Taylor Hedberg
automatically turning on. The plugin just auto-closes matching
delimiters, like parentheses, brackets, etc. However, the auto-closing
behavior turns on by default in every buffer, whereas I would prefer it
to be off by default, but toggleable via the :DelimitMateSwitch command
that the plugin provides.
You can stop it from loading in general by setting loaded_delimitMate. I
could do it globally in my .vimrc, but that would prevent the plugin
from loading altogether, meaning that not just the auto-closing behavior
would be turned off, but so would the commands to toggle it on. What I
want is for it to still load (so that the commands that the plugin
provides are still available), but not actually take effect in any
buffer automatically. If you set loaded_delimitMate in buffer scope
rather than globally, it has exactly this effect.
So all I want to do is to automatically set b:loaded_delimitMate in
every buffer when the buffer is first loaded, including no-name buffers.
That seems more difficult than I expected it to be. I don't understand
why so many autocommand events are not triggered for no-name buffers.
The BufWinEnter event you mentioned does work in no-name buffers, but
it's apparently being triggered after the plugin takes effect, because I
still get auto-closing parentheses when I use it.
Really, the plugin should just include an option to be off by default,
but it doesn't. You can turn it off for specific filetypes, but there's
no way to say "all filetypes". Maybe I'll just modify it myself to work
that way, if no one has any better suggestions.
Ben Fritz
first buffer.
Taylor Hedberg
> Just set b:loaded_delimitMate in your .vimrc. It will apply to the
> first buffer.
Good call, but it still won't apply to other "no name" buffers besides
the first one though.
I ended up just making a small modification to the plugin, to add an
option to do what I want.
Ben Fritz
On Aug 25, 2:43 pm, Taylor Hedberg <tmhedb...@gmail.com> wrote:
> Ben Fritz, Thu 2011-08-25 @ 12:30:28-0700:
>
> > Just set b:loaded_delimitMate in your .vimrc. It will apply to the
> > first buffer.
>
> Good call, but it still won't apply to other "no name" buffers besides
> the first one though.
>
autocmd BufEnter * if !exists('b:created') | let b:created = 1 | let
b:loaded_delimitMate = 1 | endif
On the other hand, this is probably something to send to the plugin
author as a feature addition.
Taylor Hedberg
> Does BufEnter work?
>
> autocmd BufEnter * if !exists('b:created') | let b:created = 1 | let
> b:loaded_delimitMate = 1 | endif
Yeah, in retrospect, that would probably do it. But I've fixed it
another way now, so I'm not going to bother.
> On the other hand, this is probably something to send to the plugin
> author as a feature addition.
Way ahead of you there. :) I forked the plugin on Github and sent him my
new option as a pull request.
Thanks for your suggestions.
Tony Mechelynck
> Ben Fritz, Thu 2011-08-25 @ 13:41:20-0700:
>> Does BufEnter work?
>>
>> autocmd BufEnter * if !exists('b:created') | let b:created = 1 | let
>> b:loaded_delimitMate = 1 | endif
>
> Yeah, in retrospect, that would probably do it. But I've fixed it
> another way now, so I'm not going to bother.
That would probably do it, at the cost of testing the condition at every
buffer switch. I think fixing the script (but not in $VIMRUNTIME) and
sending a diff to the maintainer is the way to go.
>
>
>> On the other hand, this is probably something to send to the plugin
>> author as a feature addition.
>
> Way ahead of you there. :) I forked the plugin on Github and sent him my
> new option as a pull request.
>
>
> Thanks for your suggestions.
>
Best regards,
Tony.
--
Johnson's First Law:
When any mechanical contrivance fails, it will do so at the
most inconvenient possible time.