To allow the plugin to be used for Drupal files which are not in a Drupal project directory, the b:Drupal_info.CORE and b:Drupal_info.DRUPAL_ROOT need to be set manually. As brought up in comment 4 on #1903214.

I spend a fair chunk of time reading source for modules, and just git-clone them to some random directory, so it would be useful to be able to simply do a :set ft+=.drupal and get the functionality of this plugin.

Being able to set these as user preferences would suit developers like me really well, as I tend to use the same core version of Drupal for long periods, and also have the Drupal source for all versions kicking around in my projects directory.

So, being able to have the following options in my .vimrc would be pretty sweet:

let g:DrupalDefaultCore = '7'
let g:DrupalDefaultRoot = '~/projects/drupal/7.19'

I'll play around in the next few days and try to knock up a patch for it. Any thoughts?

CommentFileSizeAuthor
#4 vimrc-core-1908966-4.patch1.07 KBbenjifisher
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

benjifisher’s picture

Category: feature » support
Status: Active » Postponed (maintainer needs more info)

If you have the entire module directory, then the package should be able to find the .info file and set CORE from that. Then, if you have set g:Drupal_dirs in your vimrc file, you should be in good shape.:help g:Drupal_dirs
(I do not think this option is in the on-line docs, yet.)

Let me know if any of this is not working.

takeontom’s picture

That's awesome!

Not sure why, but it doesn't seem to work with the Views:

cd not-in-a-drupal-project
git clone --recursive git://drupalcode.org/project/views.git
cd views
vim
:e views.module
:set ft
filetype=php

With Token, it correctly detects files as being Drupal files, but I'm unable to go to a tag:

cd token
vim
:e token.module
:set ft
filetype=php.drupal
:echo g:Drupal_dirs
{'7': '~/Projects/drupal/7.19'}
:tag hook_menu
E429: File "/home/tom/Projects/tom-vim/vim/bundle/vimrc/bundle/vim-plugin-for-drupal/tagfiles/$DRUPAL_ROOT/modules/system/system.api.php" does not exist
takeontom’s picture

If it helps, when I'm editing a Drupal file in a Drupal project, then I am able to go to a tag.

It only seems to happen when editing a Drupal file in a module project.

benjifisher’s picture

Title: Allow the CORE and DRUPAL_ROOT settings to user preferences » Allow the CORE and DRUPAL_ROOT settings to user preferences and set CORE when there are multiple .info files
Category: support » bug
Status: Postponed (maintainer needs more info) » Needs review
FileSize
1.07 KB

You can get an idea of what is going wrong with:echo b:Drupal_info
(If you are running a GUI version, then there is a menu item under Drupal.Configure.)

The problem with Views is that it contains two info files: views.info and views_ui.info. The script was not expecting glob() to return multiple files. The attached patch should fix that. In limited testing, it works with or without the first patch in #1903214: You're munging my non-Drupal PHP files.

Let's keep one bug per issue. If there is still a problem with tags, please open a new issue. Or wait until I get around to testing it.

takeontom’s picture

Thanks for the patch Benji, I'll give it a test.

takeontom’s picture

Hi, can confirm your patch fixes the Views Module not being detected as a Drupal project, with or without the patches from #1903214.

Tested within a Drupal project, outside a Drupal project (i.e. just in a module project) and confirmed that your patch does not interfere with the patches from #1903214 (i.e. I can still prevent my PHP files from being munged :) )

The tag problem still exists however, so will create a new issue.

takeontom’s picture

Benji, are you waiting for anything further from me on this? As far as I know, the patch ready to be merged.

benjifisher’s picture

Status: Needs review » Closed (duplicate)

I was waiting for a review of #1903214: You're munging my non-Drupal PHP files. See #7 on that issue. That issue has a huge reorganization of the code, which would prevent the patch in #4 above from applying.

I think I will close this issue, since an equivalent fix is incorporated in the other issue.