On 31/10/11 20:16, Дмитрий Франк wrote:
when executing autocommands, bufnr('<afile>') always return -1,
bufname('<afile>') returns empty, but expand('<afile>') works.
Ugly workaround is to use bufnr(expand('<afile>'))
I can reproduce this (on gvim 7.3.353 (Huge) with GTK2/Gnome2 GUI) but
it seems intentional:
After
:augroup testafile | exe 'au! BufRead,BufNewFile * echo ''<afile>''
bufnr(''<afile>'') bufname(''<afile>'')' | augroup END
hitting the F1 key gives me
<afile> -1
After
:augroup testafile | exe 'au! BufRead,BufNewFile * echo ''<afile>''
bufnr(expand(''<afile>'')) bufname(expand(''<afile>''))' | augroup END
it gives
<afile> 52 /usr/local/share/vim/vim73/doc/help.txt
showing that '<afile>' means just seven characters starting with
less-than and ending with greater-than, so in most cases it must be fed
to expand() to get a filename. Similarly with '#' and '%'. The
exception, maybe (I didn't test) is in the argument to :e[dit], :new,
:vie[w], :sv[iew], and other ex-commands which expect a file name.
If (at least on a Unix-like system) you had previously done
:e ./\<afile\>
then (again, I didn't test), bufnr('<afile>') and bufname('<afile>')
might give you the number and name of this strangely-named buffer.
Best regards,
Tony.
--
Predestination was doomed from the start.
--
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
