A.J.Mechelynck wrote:
Elliot Shank wrote:
It looks like FileType and Syntax events can occur between BufNewFile
and BufWinEnter, but this only happens for files that a file type can
be figured out for. If I edit a non-existent file called "blah",
there aren't any events between BufNewFile and BufWinEnter.
To run an autocommand after the last of the Syntax autocommands have
been run, define it at the VimEnter event:
au VimEnter * au BufRead,BufNewFile *.foo call MyFooFunc()
This won't work because VimEnter happens after BufNewFile for a new Vim process.
(Note: BufRead and BufReadPost are synonymous).
I prefer BufReadPost because it is clearer to the naive reader when the event
will occur.
BufWinEnter is triggered when a buffer gets displayed in a window, even
if it is already displayed in another window (e.g. after ":split" with
no arguments). Thus it can be triggered more than once for the same
buffer, while BufReadPre, BufRead, Filetype and Syntax (among others)
are normally triggered only once in that order. (Of course, if the
filetype cannot be detected for some file, neither Filetype nor Syntax
will fire).
Yes, I realize that BufWinEnter and the others can fire multiple times. I'm
assuming that the plugin that wants to listen to one of those events can handle
it.
So that we can get a clear picture of what's happening, I'll list the entire series of events that
happen if I enter "gvim foo" at the shell prompt, and, once the window has completely
come up, do a ":q":
SourcePre $VIM/vimrc
SourcePre $VIMRUNTIME/macmap.vim
SourcePre $VIMRUNTIME/autoload/paste.vim
SourcePre ~/.vimrc
SourcePre $VIMRUNTIME/filetype.vim
SourcePre $VIMRUNTIME/menu.vim
SourcePre $VIMRUNTIME/ftplugin.vim
SourcePre $VIMRUNTIME/indent.vim
SourcePre $VIMRUNTIME/syntax/syntax.vim
SourcePre $VIMRUNTIME/syntax/synload.vim
SourcePre $VIMRUNTIME/syntax/syncolor.vim
SourcePre $VIMRUNTIME/colors/desert.vim
SourcePre $VIMRUNTIME/syntax/syncolor.vim
SourcePre $VIMRUNTIME/syntax/syncolor.vim
SourcePre $VIMRUNTIME/syntax/syncolor.vim
ColorScheme ./foo
SourcePre ./.vimrc
SourcePre ./.exrc
SourcePre ~/.vim/plugin/a.vim
SourcePre ~/.vim/plugin/manpageview.vim
SourcePre ~/.vim/plugin/matchit.vim
SourcePre ~/.vim/plugin/showmarks.vim
SourcePre ~/.vim/plugin/svn.vim
SourcePre ~/.vim/plugin/svn_commit.vim
SourcePre ~/.vim/plugin/svncommand.vim
SourcePre ~/.vim/plugin/taglist.vim
SourcePre ~/.vim/plugin/vimballPlugin.vim
SourcePre $VIMRUNTIME/plugin/getscript.vim
SourcePre $VIMRUNTIME/plugin/gzip.vim
SourcePre $VIMRUNTIME/plugin/matchparen.vim
SourcePre $VIMRUNTIME/plugin/netrwPlugin.vim
SourcePre $VIMRUNTIME/plugin/rrhelper.vim
SourcePre $VIMRUNTIME/plugin/spellfile.vim
SourcePre $VIMRUNTIME/plugin/tarPlugin.vim
SourcePre $VIMRUNTIME/plugin/tohtml.vim
SourcePre $VIMRUNTIME/plugin/vimballPlugin.vim
SourcePre $VIMRUNTIME/plugin/zipPlugin.vim
SourcePre ~/.vim/after/plugin/test_after_plugin.vim
SourcePre $VIMRUNTIME/menu.vim
SourcePre $VIM/gvimrc
SourcePre ~/.gvimrc
SourcePre ./.gvimrc
GUIEnter ./foo
FocusGained ./foo
FocusGained ./foo
BufNewFile ./foo
BufWinEnter ./foo
VimEnter ./foo
FileChangedShellPost ./foo
CursorMoved ./foo
BufWinLeave ./foo
BufUnload ./foo
VimLeavePre ./foo
VimLeave ./foo
The second column is the value of <amatch> for each event, cleaned up to be shorter and
more generally explicative. As you can tell by the second event, I'm running on a Mac. Also,
it's pretty obvious that I turn on 'exrc' in ~/.vimrc. The test_after_plugin.vim file simply
contains "echo 'bletch'", just to show where an after plugin gets sourced.
As you can see, since there are no file types that match "foo", there aren't
any FileType or Syntax events.
So, assume that there's something like "autocmd BufNewFile * silent 0r somefile" in one
of the plugins or rc files and there's a plugin that's got a "autocmd BufWinEnter *
whatever" in it. How do I guarantee that I can get a plugin to run something between the two?
I don't think that there's any way to do it. Basically, the problem is that the .gvimrc
files get loaded after even the "after" plugins get loaded and they can, of
course do anything that they want.
Now that I've gone through this, forgetting about .gvimrc, you can actually accomplish
this by putting the plugin in ~/.vim/after/plugin/ with a name like
"~~~~~~~~blah.vim", if you're stuck with a filesystem that only supports
(strict) ASCII. For a filesystem with Unicode support, you want the prefix to consist of
the visible character with the highest position in Vim's sort order; the problem is
dealing with new characters that are added to Unicode.
As of the Unicode 5.0 standard released last month, it looks like the current highest ordinal
number that is visible is 2FA1D, "CJK COMPATIBILITY IDEOGRAPH-2FA1D", though I don't have
any font on my machine which has anything for the code point. There is the interesting Tags block,
but I'm not sure that any of the points in that block are supposed to be visible. It would be nice
to be able to use E007E, "TAG TILDE", but the Mac character palette won't even show
placeholders for the block, though it is listed. Which means, I guess, that the code points in the
Tags block isn't supposed to be visible.
*sigh*
Anyone working in a CJK language environment have any suggestions?
