Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#10 | vimrc-munge-1903214-10.patch | 39.11 KB | benjifisher |
#7 | vimrc-munge-1903214-7.patch | 38.22 KB | benjifisher |
#4 | vimrc-munge-1903214-4.patch | 814 bytes | takeontom |
#1 | vimrc-munge-1903214-1.patch | 714 bytes | benjifisher |
Comments
Comment #0.0
takeontom CreditAttribution: takeontom commentedLogic issues :)
Comment #1
benjifisherThere 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?
Comment #2
takeontom CreditAttribution: takeontom commentedHi,
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.
I noticed the following issues for PHP files in non-Drupal projects:
... 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":
Comment #3
benjifisherThanks. 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.
Comment #4
takeontom CreditAttribution: takeontom commentedHello,
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:
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 ofb:Drupal_info
to be skipped.How do you feel about the attached patch? It sets the
b:Drupal_info
regardless of whetherinfo.CORE
has been set. This obviously has the downside of settingb: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. :)
Comment #5
benjifisherI 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.
Comment #6
benjifisherupdating status
Comment #7
benjifisherI 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.
Comment #8
takeontom CreditAttribution: takeontom commentedGood 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:
Setting filetype to "drini.drupal" for info files:
Lookup Drupal Function
\da
,\dc
&\dda
E117: Unknown function: <SNR>88_OpenURL
E117: Unknown function: <SNR>88_OpenURL
E117: Unknown function: <SNR>88_OpenURL
Tag Lookup
:tag hook_menu
SnipMate snippets
hook_menu<tab>
Comment #9
takeontom CreditAttribution: takeontom commentedJust 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:
To recreate:
However, if I try opening the same file on a Drupal project which has simply been cloned from git, the error does not occur:
Comment #10
benjifisherThanks 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):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.
Comment #11
takeontom CreditAttribution: takeontom commentedSorry 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.Comment #12
benjifisherI 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.
Comment #13
benjifisherI 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.
Comment #14
benjifisherI 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.
Comment #15.0
(not verified) CreditAttribution: commentedFix a typo.