Hi,

All my non-Drupal PHP files are having their filetype set to php.drupal.

I believe this is caused in plugin/drupal.vim:

  " TODO:  If we are not inside a Drupal directory, maybe skip this.  Wait
  " until someone complains that we are munging his non-Drupal php files.
  set ft+=.drupal

I would expect PHP files to be left alone, unless they're inside a Drupal project.

I believe this could be fixed by simply checking info.CORE. Something like this:

if info.CORE != ''
  set ft+=.drupal
endif
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

takeontom’s picture

Issue summary: View changes

Logic issues :)

benjifisher’s picture

Status: Active » Needs review
FileSize
714 bytes

There is a reason for that comment: I need someone to test the fix, and I figure I will get more vigorous testing from someone who is affected by the issue. I hope you are willing to do that testing. I also need to test that the fix does not miss too many Drupal files, but I suppose I will hear about it if it does.

What settings (or other effects) were annoying you when editing non-Drupal files?

takeontom’s picture

Hi,

Thanks for the patch.

I'm more than happy to test this. I'll use it for both Drupal and non-Drupal PHP projects for a few days and feedback any issues I find.

Is there anything other than potentially missing Drupal files that you're worried this patch might introduce? Let me know and I'll test those too.

What settings (or other effects) were annoying you when editing non-Drupal files?

I noticed the following issues for PHP files in non-Drupal projects:

  • Drupal specific syntax highlighting is used
  • Tag List no longer displays any results
  • EasyTags can't auto-generate tags as it passes the filetype of "php.drupal" to ctags
  • My preferences for tabstops, shiftwidth, textwidth, etc. are overridden

... but, I'm sure that list only scratches the surface. Any functionality that relies on the PHP filetype being correctly set is likely going to suffer.

I am also prevented from manually setting the filetype of a non-Drupal project PHP file back to "php" after it has been set to "php.drupal":

:set filetype
filetype=php.drupal
:set filetype=php
:set filetype
filetype=php.drupal
benjifisher’s picture

Thanks. I look forward to more feedback.

I do not think the patch will have any side effects besides possibly treating some Drupal files as plain PHP (or javascript ...).

TagList has not been updated for Vim 7, so it does not handle compund filetypes (if that is the correct term) like php.drupal. I do not know any reason not to switch to the more recent TagBar. (TagBar is one of the plugins that gets installed if you use drush -v vimrc-install.) I have not looked at Easy Tags, but I consider it a bug if it does not handle compound filetypes.

Your last point is related to a quirk I noticed recently, but I think I will open a separate issue for that: #1905604: Find a better way to set filetype.

takeontom’s picture

FileSize
814 bytes

Hello,

I've been using this patch successfully for 5 days.

I couldn't find any instances of a Drupal file (PHP, JavaScript, Make or Info) within a Drupal 7 project that were ignored.

I had only 1 issue:

If I'm viewing a Drupal file that's outside of a normal Drupal project (e.g. if I've git-cloned a module into a separate directory to browse its source or something), if I attempt to set the filetype to php.drupal I (predictably) get the following:

:set filetype=php.drupal
Error detected while processing /home/users/tom/Projects/tom-vim/vim/bundle/vimrc/bundle/vim-plugin-for-drupal/ftplugin/drupal.vim:
line   18:
E121: Undefined variable: b:Drupal_info
E116: Invalid arguments for function strlen(b:Drupal_info.INFO_FILE)
E15: Invalid expression: strlen(b:Drupal_info.INFO_FILE)
line   21:
E121: Undefined variable: b:Drupal_info
E116: Invalid arguments for function strlen(b:Drupal_info.DRUPAL_ROOT)
E15: Invalid expression: strlen(b:Drupal_info.DRUPAL_ROOT)
line   24:
E121: Undefined variable: b:Drupal_info
E116: Invalid arguments for function strlen(b:Drupal_info.CORE)
E15: Invalid expression: strlen(b:Drupal_info.CORE)
line  148:
E121: Undefined variable: b:Drupal_info
E116: Invalid arguments for function strlen(b:Drupal_info.OPEN_COMMAND)
E15: Invalid expression: strlen(b:Drupal_info.OPEN_COMMAND)

This is because the DrupalInit() function (correctly) can't discover Drupal's version, which results in info.CORE being empty, which then causes the setting of b:Drupal_info to be skipped.

How do you feel about the attached patch? It sets the b:Drupal_info regardless of whether info.CORE has been set. This obviously has the downside of setting b:Drupal_info on all potential Drupal files and will not contain the CORE or DRUPAL_ROOT, which prevents the tags, snippets and function lookup features of your plugin from working... but it does stop the error.

I've added issue #1908966 which suggests adding user defined defaults for the CORE and DRUPAL_ROOT settings.

Thanks for the heads up on TagBar, much prefer it to TagList. :)

benjifisher’s picture

I think I would rather rearrange the code so that b:Drupal_info is set at the beginning of ftplugin/drupal.vim. That way, I will not add any clutter (such as a buffer-local variable) to non-Drupal files. Maybe cache the values in a script-local variable so that we do not have to figure out CORE and DRUPAL_ROOT twice.

I have also been thinking that all the functions used in the ftplugin should be defined in the autoload file.

benjifisher’s picture

Status: Needs review » Needs work

updating status

benjifisher’s picture

Status: Needs work » Needs review
FileSize
38.22 KB

I implemented my suggestion in #5. One advantage is that I took two or three hundred lines out of plugin/drupal.vim, so they will not be loaded every time vim starts up.

In brief testing, this works as well as the patch in #1, and solves the problem described in #4.

This is a terrible patch, in the sense that it does too many things. It changes comment formatting, moves functions between files, adds caching, and more. I should be more careful when this project comes out of alpha status.

I have marked #1905604: Find a better way to set filetype as a duplicate.

This patch incorporates the one from #1908966-4: Allow the CORE and DRUPAL_ROOT settings to user preferences and set CORE when there are multiple .info files. Once this issue is marked RTBC, I will mark that issue as a duplicate.

takeontom’s picture

Good work Benji.

Have tested all features that I know about in your script. Details are below. To summarise: everything seems to work apart from the lookup functionality (i.e. \da, \dc & \dda)

Appending ".drupal" to PHP & Javascript filetypes:

  • Full Drupal project = ok
  • Module project = ok
  • Module project with multiple info files (e.g. Views) = ok

Setting filetype to "drini.drupal" for info files:

  • Full Drupal project = ok
  • Module project = ok
  • Module project with multiple info files (e.g. Views) = ok

Lookup Drupal Function

\da, \dc & \dda

  • Full Drupal project = fail: E117: Unknown function: <SNR>88_OpenURL
  • Module project = fail: E117: Unknown function: <SNR>88_OpenURL
  • Module project with multiple info files (e.g. Views) = fail: E117: Unknown function: <SNR>88_OpenURL

Tag Lookup

:tag hook_menu

  • Full Drupal project = ok
  • Module project = ok
  • Module project with multiple info files (e.g. Views) = ok

SnipMate snippets

hook_menu<tab>

  • Full Drupal project = ok
  • Module project = ok
  • Module project with multiple info files (e.g. Views) = ok
takeontom’s picture

Just come across another problem which I can only recreate following your patch:

On a full Drupal 7 project which has been created via Drush, when I load a .inc file the following error occurs:

Error detected while processing /home/tom/Projects/tom-vim/vim/bundle/vimrc/bundle/vim-plugin-for-drupal/autoload/drupal.vim:
line   67:
E122: Function drupal#CreateMaps already exists, add ! to replace it
Error detected while processing function drupal#DrupalInfo..drupaldetect#InfoPath:
line   23:
E121: Undefined variable: list
E15: Invalid expression: list[0]
line   24:
E121: Undefined variable: list
E15: Invalid expression: list[0]
line   23:
E121: Undefined variable: list
E15: Invalid expression: list[0]
line   24:
E121: Undefined variable: list
E15: Invalid expression: list[0]

To recreate:

cd somewhere-random
drush dl drupal-7.x
cd drupal-7.x-dev
vim includes/file.inc

However, if I try opening the same file on a Drupal project which has simply been cloned from git, the error does not occur:

git clone -b 7.x --depth 1 git://drupalcode.org/project/drupal.git
cd drupal
vim includes/file.inc
benjifisher’s picture

FileSize
39.11 KB

Thanks for all the testing! I think I understand two of the three problems.

The problem with \da and friends in #8 is because when I moved functions out of the plugin file and into the autoload file, I missed updating calls to one of them. Given all the changes I made, it is not surprising that I missed one or two.

The list/list[0] problem is a garden-variety programming mistake. I changed my mind about how to name a variable and forgot to update two instances. You only reach those lines of code if the script cannot find a .info file. (Neither the Drupal root directory nor includes/ contains a file with the extension .info.) The script keeps looking up the path until it finds a file with extension .info, .make, or .build: I think it must have found one in your test.

I do not understand why vim should be redefining drupal#CreateMaps(). The file autoload/drupal.vim is only supposed to be :source'd once. Maybe I am running into this warning (see :help autoload):

Note that when you make a mistake and call a function that is supposed to be defined in an autoload script, but the script doesn't actually define the function, the script will be sourced every time you try to call the function. And you will get an error message every time.

So I could fix the problem by adding "!", as the error message suggests, but I am afraid that might be fixing the symptom instead of the cause.

Please check whether you can still reproduce the first error in #9. I was not able to, using /tmp as "somewhere-random". I think the attached patch should fix the other problems.

takeontom’s picture

Sorry for the wait, I've not had a dev environment to test your patch until now.

Not sure what was going on, but I can't now recreate the error in #9. Have tried with patch #10, patch #7 and no patch. I was originally able to cause the issue on both my main dev machine and also on a clean vagrant box. So there might still be an issue around, or I was doing something insanely weird.

How interested are you in problem I found in #9? I don't know whether it's pointing towards a fairly serious problem that needs to be investigated further, or was just some crazy fluke.

Can confirm that the /da, /dc and /dda work with the #10 patch.

benjifisher’s picture

Status: Needs review » Reviewed & tested by the community

I will take the comments in #11 as equivalent to RTBC. @takeontom, please update the status when you review a patch. If I have marked it "needs "review" (NR) and you review it, you can change the status to "needs work" or "reviewed & tested by the community" (NW or RTBC) as appropriate.

As I said in #7 above, I am marking #1908966: Allow the CORE and DRUPAL_ROOT settings to user preferences and set CORE when there are multiple .info files as a duplicate of this issue. Not because the bugs are the same, but because I rolled the fix for that issue into the patch in #7 above.

benjifisher’s picture

I am not too eager to track down a hard-to-reproduce bug. As I said in #10, I prefer not to treat the symptom. If there is a bug in there, we will see it again.

benjifisher’s picture

Status: Reviewed & tested by the community » Fixed

I have been busy for the last couple of months, but it is finally time to commit the patch in #10: 40fa87d.

As I said in #10, the patch there does too many things at once. So I did "git merge", preserving the four commits I made while developing the patch, instead of "git apply". The commit referenced above is a dummy, mostly there to point to this issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Fix a typo.