Elliot Shank wrote:
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.
IU mentioned the VimEnter event, which is triggered at the very end of
startup. It is of course possible that other scripts than your own will
set up VimEnter autocommands to create new autocommands in their turn,
but IMHO it is highly unlikely.
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?
AFAIK, Vim doesn't show "proper" glyphs for codepoints higher than
U+FFFF (on my system it shows double-width question marks for CJK "wide"
characters in the block starting at U+20000). It can enter them though
(for instance as shown under ":help i_CTRL-V_digit") and the Normal-mode
ga command will show the actual value of whatever is under the cursor.
In Unihan.txt version 5.0.0, I have for that "last character" (the
"highes" CJK codepoint) the three lines
U+2FA1D kCompatibilityVariant U+2A600
U+2FA1D kIRG_TSource 7-5E4D
U+2FA1D kRSUnicode 211.6
meaning, among others, that it is a "radical 211 + 6 strokes" variant of
codepoint U+2A600 which has more lines in the database but still no
kDefinition.
Best regards,
Tony.
