UltiSnips fdetect autocmd conflicts with --noplugin

Bug #1278590 reported by Lucas Hoffmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
UltiSnips
Fix Committed
Undecided
Unassigned

Bug Description

Bug: On startup with `vim --noplugin` (or `set noloadplugins` in some rc file) I get an Error:
> Error detected while processing FileType Auto commands for "*":
> E117: Unknown function: UltiSnips_FileTypeChanged

Problem: The file ftdetect/UltiSnips.vim (creating the autocmd) is loaded but not the file plugin/UltiSnips.vim which would define the function.

Possible solutions: I'm not familiar with UltiSnips code base so I can only guess: Either you could remove the code from fdetect, the comment at the top of the file states:
> " This has to be called before ftplugins are loaded. Therefore
> " it is here in ftdetect though it maybe shouldn't
Or you can change the relevant UltiSnips functions (or all UltiSnips functions) to be autoloading functions. I just tested it and it seems that autoload functions still work with --noplugin. I am not sure of any other consequences from using autoloading functions.

System:
1. Arch Linux, vim 7.4.135, not sure about UltiSnips version (there are no versions in the code), I installed UltiSnips with pacman and `pacman -Qi vim-ultisnips` reports "Version: 2.2-1".
2. Mac OS X 10.9, vim 7.4.52, UltiSnips installed with Vundle, commit f6b197e18ee34c0d1f8f2d9f787e49829aa4431b of the official github repository

Revision history for this message
SirVer (sirver) wrote :

> Bug: On startup with `vim --noplugin` (or `set noloadplugins` in some rc file) I get an Error:

oh noooo - yet another obscure vim option that does not work as advertised. Why would someone install plugins and then not use them?

> Either you could remove the code from fdetect

Well, as you will have guessed the code is there for a reason - there is no other way to be loaded before all kinds of ftplugins but we need to be the first to be called when the filetype changes - so this hack is necessary to work around the limitations of Vim.

> Or you can change the relevant UltiSnips functions (or all UltiSnips functions) to be autoloading functions.

I did that now. I did not do it in the past because it felt moot - since we need to keep track of all CursorMoved commands anyways, the full plugin is always loaded. Now it is only loaded when you use the Cursor in insert mode - which will be always too. So autoload did not buy us anything for UltiSnips. However, moving the methods into autoload seems to have solved your --noplugin issues, check out https://github.com/SirVer/ultisnips/commit/82ca377aaff84eae9d0230e9941685901b226db4 and let me know if there are any problems.

Changed in ultisnips:
status: New → Fix Committed
Revision history for this message
Lucas Hoffmann (l-m-h) wrote : [Bug 1278590] Re: UltiSnips fdetect autocmd conflicts with --noplugin

Thank you for the fast reaction. It works!

> Why would someone install plugins and then not use them?
I'm using [vimpager](https://github.com/rkitover/vimpager) as my pager
and I set noloadplugins in my vimpagerrc. Other use cases might be
debugging or scripting (yes, some people use vim as an interpreter to
run scripts from command line).

Lucas

Revision history for this message
SirVer (sirver) wrote :

vim as pager is an odd idea indeed - Vim already aches and nearly breaks when I watch my log files at work and they are at most 200MB, using it as pager seems not the ideal use case. To each his own I guess :)

Glad that the fix did work for you.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.