autocmd BufAdd/BufCreate/BufNew aren't triggered for new, unnamed buffers (`:enew`)?

Question

I'm trying to set up an autocommand so that new, unnamed buffers are created with ft=markdown. Someone on SO suggested the following:

autocmd BufEnter * if &filetype == "" | setlocal ft=markdown | endif

which works great, but with which I have the following gripes:

1. this will set ft=markdown on named buffers, too (e.g., :e foo), and
2. this will run every time I switch to (enter) the buffer, not just when it's first created — not a problem in practice, but not what I want to do in principle.

---

I've been working through the problem myself, but I can only get halfway there.

Success: the right autocmd {pat}

I've figured out that I can specify unnamed buffers by using a pair of empty curly braces ({}) in place of a filename pattern. That is,

autocmd VimEnter {} setlocal ft=markdown

will run on $ vim, but not on $ vim foo.

Failure: the right autocmd {event}

So now I'm looking for the right autocmd event: one that is triggered on :enew or any other time a blank, unnamed buffer is added to the buffer list. I've tried:

• BufAdd
• BufCreate
• BufNew

but none of these are triggered on :enew. I've tested this with the following autocommands:

autocmd BufAdd    * let b:foo = 'foo'
autocmd BufCreate * let b:foo = 'foo'
autocmd BufNew    * let b:foo = 'foo'

When I edit an existing file, :echo exists('b:foo') returns 1. When I :enew, it returns 0.

(To be clear, BufEnter still works, but I'm looking for one that only runs once.)

Is there an appropriate autocmd here, or should I file a bug?

Answer 1

At first I was thinking of listening for BufNewFile, but this is not the right event. My mistake.

I had the confirmation thanks to a plugin given in another answer: http://vi.stackexchange.com/questions/4493/what-is-the-order-of-winenter-bufenter-bufread-syntax-filetype-events

->

- BufNew -- 
- BufAdd -- 
- BufCreate -- 
- BufLeave -- /tmp/vim_log_autocommands
- BufEnter -- 
- BufWinEnter -- 

So, I've tested with your events:

aug Test
  au!
  au BufAdd    * :echom "Add ".expand('<amatch>')."--".bufnr('%') | let b:test = 1
  au BufCreate * :echom "Create ".expand('<amatch>')."--".bufnr('%') | let b:test = 1
  au BufNew    * :echom "New ".expand('<amatch>')."--".bufnr('%') | let b:test = 1
aug END

If you look closely, we see, first that the events are correctly triggered, and then that the buffer created isn't bufnr('%'). Hence <amatch> that is the proper way to proceed in many autocommands. This is hinted in the documentation:

NOTE: When this autocommand is executed, the current buffer % may be different from the buffer being created <afile>.

If you go back to the buffer (corresponding to the number printed), you'll see that b:test is set to 1 over there. Actually you can expect the number of the new buffer to be bufnr('$')+1. Still, I wouldn't use setbufvar() as getbufinfo(bufnr('%')+1) is still empty.

That's why in the other answer, you were pointing to, they said to listen for BufEnter I guess. Instead, you'll have to mark the buffers you've already tested.

• Either you use an internal variable at your script level

  let s:been_there = {}
  aug FTOverride
    au! 
    " untested
    au BufEnter * if empty(&ft) && !get(s:been_there, bufnr('%'), 0) | set ft=markdown | let s:been_there[bufnr('%')] = 1 | endif
  aug END
  

• Or you use a buffer variable which will be visible by everyone

  ...
    " untested
    au BufEnter * if empty(&ft) && !get(b:, 'ft_overridden', 0) | set ft=markdown | let b:ft_overridden = 1 | endif
  

EDIT2: In a personal plugin I'm maintaining, I've found another way to proceed. This time I listen for the root events. When triggered, I register an one-time-autocommand on BufEnter:

augroup auto_jump_to_line
  au!
  au BufNewFile,BufWinEnter *:* nested
        \ call lh#event#register_for_one_execution_at('BufEnter', function(s:getSNR('FixFilename')), 'auto_jump_to_line_1', expand('<afile>:t'))
augroup END

Where lh#event#register_for_one_execution_at() registers an autocommand that'll start by un-registering itself. I haven't checked in your case, but it may work. But choose only one autocommand among the 3 you've found.