Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subdirectories of bundles are not parsed for addition to rtp #46

Open
jmcaffee opened this issue Oct 17, 2011 · 13 comments
Open

Subdirectories of bundles are not parsed for addition to rtp #46

jmcaffee opened this issue Oct 17, 2011 · 13 comments

Comments

@jmcaffee
Copy link

I'm running Vim 7.3 on windows 7.
The issue I'm having is that the after dir is not being added to the rtp for the snipmate plugin. The snipmate dir structure is:
~\vimfiles\bundle\snipmate
~\vimfiles\bundle\snipmate\after

From debugging, it looks like ~\vimfiles\bundle\snipmate is added to rtp but no directories under snipmate are added.
By moving ...\snipmate\after dir to directly under bundle, the directory is added as expected.

I am running the latest version of pathogen and from reviewing the issues log, I have verified that previous fixes to pathogen#runtime_append_all_bundles() are in the version of pathogen I've got installed.

@jmcaffee
Copy link
Author

I found that changing:
.sep.'*[^~]'

to:
.sep.'**[^~]'

in lines 153 and 155 results in the 'after' dirs being included in the rtp.

I don't know if it's an issue (or matters) but the 'after' dirs are included in the middle of the list produced by :scriptnames and I'm expecting them at the end. ie. they come 'after' all other *.vim files. My snipmate plugin is still not working (maybe because of this?)

@graudeejs
Copy link

snipmate worked fine for me with pathogen

@tpope
Copy link
Owner

tpope commented Oct 21, 2011

@jmcaffee, that solution causes every single directory inside every single bundle to be added, surely not what you had in mind.

As a first step, can you post the output of :set runtimepath? when pathogen is not activated?

@sunaku
Copy link

sunaku commented Oct 21, 2011

Hint: run vim -u NONE -c 'set runtimepath?'

@jmcaffee
Copy link
Author

You are correct about every single directory being added. And it appears that there is a limit on the length of the runtimepath that I am now hitting...

Here's the runtime path:
C:\Users\killer/vimfiles,C:\tools\vim/vimfiles,C:\tools\vim\vim73\runtime,C:\tools\vim/vimfiles/after,C:\Users\killer/vimfiles/after

@tpope
Copy link
Owner

tpope commented Oct 21, 2011

I don't think there's a limit on length, just :set output length. Try :echo &runtimepath rather than :set runtimepath?

That's a weird mixture of \ and / in your runtimepath, but it should work fine.

@jmcaffee
Copy link
Author

:set runtimepath? didn't work for me. The paths listed above are a result of :echo &runtimepath (with no plugins enabled).

@tpope
Copy link
Owner

tpope commented Oct 21, 2011

Then what did you mean by a "limit on the length of the runtimepath"?

@jmcaffee
Copy link
Author

Additionally, the directory C:\tools\vim\vimfiles doesn't actually exist on my system. So, I don't know where that is coming from.

@jmcaffee
Copy link
Author

I had added ruby_debugger plugin to the bundle directory and I started getting errors about spelling files not being found. When I checked the runtimepath at that point, it was being truncated (visually, anyway) and I assumed it was because it had been made so long. I was using echo &runtimepath to check the it at the time.

Keep in mind that there are a lot of directories in the ruby_debugger tree and they were all being added due to my change (**) to the pathogen function.

After removing the ruby_debugger plugin from the bundle dir, the missing spell files errors went away.

When I started gvim using the command line given by @sunaku, set runtimepath? returned an error:
Error detected while processing command line: E20: Mark not set

Starting gvim with gvim -u NONE then running :set runtimepath? returns:

runtimepath=~/vimfiles,C:\tools\vim/vimfiles,C:\tools\vim\vim73\runtime,C:\tools\vim/vimfiles/after,~/vimfiles/after

@jmcaffee
Copy link
Author

I did want to point out that I was calling pathogen from my vimrc file with the following signature:
call pathogen#infect()
This gives me the problems mentioned above (after dirs not added to path) because it is calling pathogen#runtime_append_all_bundles()

I changed the infect call to:
call pathogen#infect("~/vimfiles/bundle")
and this gives me the desired results (due to it calling pathogen#runtime_prepend_subdirectories())

It appears that runtime_append_all_bundles() doesn't look any deeper into the directory trees than the initial level -- meaning that it would find bundle/after but not bundle/somedir/after.

I'm not sure if this is the intended result or not.

@tpope
Copy link
Owner

tpope commented Oct 23, 2011

It does look deeper once it hits the after directories in 'runtimepath'. That is, it adds ~/vimfiles/bundle/* when it hits ~/vimfiles and adds ~/vimfiles/bundle/*/after when it hits ~/vimfiles/after.

@dennishostetler
Copy link

I'm having this issue too. Under Cygwin and Linux there is not an issue with the length of the runtimepath set rtp shows everything. On Windows however 7.3.46 my rtp gets truncated at 1023 characters.

The Cygwin/Linux Vim versions are a bit newer (7.3.353/7.3.154). I wonder if the rtp limit was removed in a later patch or if it's just a Windows thing?

Never mind. I'm an idiot. It's just the path display (as you indicated earler) that's truncated. The issue is with snipmate. Not the amazingly awesome pathogen :-).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants