On Sun 30-Jul-06 2:05pm -0600, you wrote:
> Bill McCarthy wrote:
>> On Sun 30-Jul-06 4:56am -0600, Christian Ebert wrote:
>>
>>> * A.J.Mechelynck on Sunday, July 30, 2006 at 10:59:55 +0200:
>>>> Looks like AsNeeded didn't find <SID>Tlist_Session_Load in taglist
>>>> because taglist's "script number" had changed from 23 to something else,
>>>> or because taglist wasn't reloaded (yet?). Try moving taglist out of
>>>> AsNeeded's scope and having it load unconditionally. I don't know
>>>> AsNeeded well enough to know if it's a bug or not.
>>
>> I don't know what you could possible mean, Tony, by "moving
>> taglist out of AsNeeded's scope .." As I explained, both
>> AsNeeded and taglist are the only files in vimfiles\plugin.
>> There is nothing in vimfiles\AsNeeded.
>>
>>> taglist uses au FuncUndefined as its own AsNeeded mechanism. This
>>> might collide with AsNeeded.
>>
>> That leads to a work-around of sourcing taglist a second
>> time by adding to _vimrc:
>>
>> ru plugin\taglist.vim
>>
>> Perhaps a better solution is to change taglist by adding a
>> check for a global variable - if present, complete sourcing
>> without the double load mechanism.
>>
> Hm. Maybe the order in which they load is relevant? If they are in the
> same directory, Vim will (IIUC) load them in alphabetical order; but if
> one of them is in ~/.vim/plugin (or, on Windows, ~/vimfiles/plugin) and
> the other in $VIM/vimfiles/plugin, the former will be sourced before the
> latter. (And anything in $VIMRUNTIME/plugin will be sourced after both.)
The order of load doesn't appear to matter. What I think
matters is the precedence of the triggering of FuncUndefined
- here are the triggers as listed by ':au':
FuncUndefined
* call AsNeeded(1,expand("<afile>"))
*11_Tlist_*
source c:\util\home\vimfiles\plugin\taglist.vim
*11_Tlist_Window_*
source c:\util\home\vimfiles\plugin\taglist.vim
*11_Tlist_Menu_*
source c:\util\home\vimfiles\plugin\taglist.vim
Tlist_* source c:\util\home\vimfiles\plugin\taglist.vim
TagList_* source c:\util\home\vimfiles\plugin\taglist.vim
AsNeeded appears to take control first and can't find a
solution in its AsNeeded directory - so it fails.
--
Best regards,
Bill
