Add suppport for javascript and other file types.

I apologize: I accidentally committed the patch. I just do not know git well enough yet. (But I learned something today!) I do not intentionally commit my own patches without review.

Real soon now, I will propose further changes now that I have committed the patch I wanted to, from #1139024-4: Add support for Drupal Snippets for Vim. That will simplify things.

This is a big, complicated patch, but it leads to a simpler structure for this project. It is based on the idea of introducing "drupal" as a secondary filetype as in #1139024-4: Add support for Drupal Snippets for Vim, but it implements that idea in a different way, so it starts by reversing that patch (even though I just commited it yesterday). I will walk through the changes.

• I revert ftdetect/drupal.vim so that it just does :set ft=php for all our drupal PHP files. Then I add the line
  

    autocmd FileType php,css,javascript,dosini set ft+=.drupal
  

  to plugin/drupal.vim. Now our PHP files will have 'filetype' set to "php.drupal", and also our CSS files will have it set to "css.drupal" and so on.

• Now look at the ftplugin files. We no longer need ftplugin/php_drupal.vim and ftplugin/javascript_drupal.vim (and others never written) to :source ftplugin/drupal.vim. This will happen automatically once we set 'filetype' to "*.drupal". So I removed the ftplugin/*_drupal.vim files and added a few lines from the old ftplugin/php_drupal.vim to ftplugin/drupal.vim. (These lines will only be used inside PHP files.)
• Another effect of adding "drupal" as a secondary filetype is that syntax/drupal.vim will be :sourced, after the other syntax files. So I deleted the Syntax autocommands from plugin/drupal.vim and created syntax/drupal.vim. For now, all this file does is add highlighting for long comments. Trailing spaces are still dealt with in plugin/drupal.vim.
• In plugin/drupal.vim I changed the condition under which ToggleWhitespaceMatch() bails out. Now it checks whether "drupal" is part of the 'filetype'.

This version makes an improvement to syntax/drupal.vim, which highlights long comments as errors. I noticed that in

/* This is a long comment in a CSS file that goes over 80 characters.  Maybe I really should comment out the following line */
.body {font: "Comic Sans"}

the */ was highlighted as drupalOverLength (linked to Error) and so it was not recognized as the end of the comment. Then the following line was given Comment highlighting.

The fix is not perfect. If you do something odd like

// Start a long comment that goes over 80 characters over 80 characters over 80 characters then */ and more

then the */ will be highlighted as Comment instead of Error, but I think that is OK. I think this version works well in most cases.

This version of the patch is a major rewrite and expansion. It makes use of the tags files described in #1347302: Tags files are too big., which I just added to the project. (I cannot include them in a patch here because they are too big.)

First, I moved a function definition from the ftplugin file to the plugin file, since the function needs to be defined only once.

Next, I used the plugin file (using a function and an autocommand or two) to look for the root of the Drupal installation and the .info file of the current project. If they are found, then the script stores some useful information, such as the Drupal core version, in a buffer-local array. (In Vim terminology, a Dictionary.)

I improved the \da mapping to go to the page on api.drupal.org so that it is aware of the version of Drupal core.

The scripts set the environment variable $DRUPAL_ROOT that is used in the tags files. This lets you use all of vim's tag-search commands. For example, put the cursor on a function such as drupal_set_message() and type <C-W>] to open drupal/includes/bootstrap.inc and jump to the definition. For more options, see
:help tag-commands
:help window-tag

The tags files are also used by the PHP auto-complete script that comes in the standard vim distribution. For example, you can type drupal_se and then <C-X><C-O> to see all completions as in the screen shot below. Note the scratch buffer at the top of the page that shows the arguments of the currently selected completion. For standard PHP functions, the scratch buffer has even more information on arguments. This also works for functions (and variables, constants, etc.) defined in the current file. See
:help compl-omni

kostajh, thanks for testing!

I do not see a problem with your setup, although maybe I need more details. If there is a problem, maybe I can tweak the method for guessing where the Drupal root is. If all else fails, I can put in a configuration option. Of course, I really want it to work without configuration.

IIUC you have something like

~/Sites/www.client.com/drupal/sites/all/modules/views/views.module
~/work/git-repos/client/sites/all/modules/views/views.module

and client is symlinked to drupal, so the two .module files are actually the same. Or maybe you leave off the drupal/ part of the path, and client is symlinked to www.client.com.

If I have it straight, then the tags files should work as is. When vim looks at expand('%:p') it should get one of the two paths above. It will test either ~/Sites/www.client.com/drupal/ or ~/work/git-repos/client/ and look for the magic file/directory names index.php, cron.php, sites, themes, and modules. If it finds them, then it will set $DRUPAL_ROOT to the directory it is testing. The tags files that I added to the project use this environment variable: they do not include any real directory, and they do not rely on finding a ctags executable on the user's system. (Isn't that clever? ;)

It will be a problem if your git repo is not a full Drupal install. If git-repos/client/ contains only the sites/ subdirectory, then my script cannot guess where to look for DRUPAL_ROOT.

@kostajh:

In that case, mark this issue RTBC and I will commit the patch. Then you can open another issue and we can add other ways to find the Drupal root.

As a work-around, you can

:let $DRUPAL_ROOT = '~/Sites/www.client.com/drupal'

for now.

@kostajh:

You might try (using the right paths, of course)

$ cd ~/work/git-repos/client
$ touch index.php cron.php
$ ln -s ~/Sites/www.client.com/drupal/modules .
$ ln -s ~/Sites/www.client.com/drupal/themes .

No, that does not work. If you apply the attached patch on top of the one from #4, I think it will work.
(You already have ~/work/git-repos/client/sites, right?)

Two questions: does this work? If so, is it a reasonable/useful option for you?

@jolos:

I think everything works as is for core or contributed modules and themes.

I already have a question in the comments in ftplugin/drupal.vim:

" TODO:  If we do not know which version of Drupal core, add no tags file or all?

How do you like the effect of

:setl tags=./tags,tags,/path/to/vimrc/drupal7.tags,/path/to/vimrc/drupal6.tags

It should work for autocompletion. If the script finds the right $DRUPAL_ROOT, it should work pretty well for tag searches, too.

Assuming we have the right $DRUPAL_ROOT, there are other ways to determine the core version. We could check the first few lines of CHANGELOG.txt, although people sometimes delete that for security reasons. We could also look at $DRUPAL_ROOT/modules/system/system.info. Comments?

@jolos:

Right, that is neither a module nor a theme. I am still not sure which of the options I described in #11 is most reliable, but let's try using $DRUPAL_ROOT/modules/system/system.info. Please try the attached patch on top of the one from #4.

If you are editing a file that has /modules/ or /themes/ in its path, then the script sets b:Drupal_info.TYPE to 'module' or 'theme'. So far, that is only used when editing a .info file, to decide which keywords get highlighted. (I will commit that code to the master branch soon!) Who knows, we might find some other use for this information later. Maybe, if the file has /includes/ in its path, we should set b:Drupal_info.TYPE to 'include'.

Since I committed other changes to the master branch, the patch in #4 no longer applies cleanly. Here is a revised patch. It includes the changes from #4, #11, and #13 above.

Because I am merging with other changes, and because I want feedback on the questions from #10 and #12, I am rolling the status back to "needs review."

Here is a version of the patch that includes documentation updates: both README.txt and doc/drupal.txt. While I was at it, I added a section on installation with pathogen to each of these files.

@jolos:

Thanks for the review! I am looking forward to getting feature requests. I agree that the b:Drupal_info variable, and the overall structure provided by this patch, will make it easier to add new features.

I have committed the patch from #15, and I am marking this issue as fixed.

@kostajh,

Does
$drush status root
give the right answer? If so, we can use that, or parse your drushrc.php (probably faster) to set b:Drupal_info.DRUPAL_ROOT.

@kostajh,

Au contraire: Perhaps you get nothing, but I get

$ drush status root
 Drupal root   :  /Users/benji/Sites/drupal

Or I get that as one line when I just type
$drush st
(In case it makes a difference, I have drush 4.5.)

If I can find the Drupal root, I can find the core version reliably from DRUPAL_ROOT/modules/system/system.info. (Add "core/" for D8.) I think you are getting the 'CORE' and 'DRUPAL_ROOT' keys mixed up. (That is understandable, since the whole system does not work with your set-up.) Anyway, I would rather get both.

For me, drush st causes a noticeable lag, and drush sa is worse. It would be annoying to go through that each time I open a module file.

Why don't you think about coercing drush into finding your Drupal install directory, and I will think about adding a manual override. (In vim, we use :let with variables, :set with built-in options; and it is the command line, not the status line.)

@kostajh,

Yes, but I want the Drupal root as well as the Drupal version. I could also use $drush status "Drupal root". I still want to know: if you do
$drush status rootwith your setup, does it tell you something useful?

@kostajh,

Can you fix something in your drushrc.php so that drush can figure it out? Or if the "root" argument is problematic, then $ drush st should output something like

 Drupal root            :  /Users/benji/Sites/drupal            

near the end.

If drush has no way to figure out your Drupal root, then we will have to do it.

The current script should be able to figure out your main Drupal version. (I assume that whatever module or theme you have comes with a proper .info file.) Does

echo b:Drupal_info.CORE

give the right answer?

@kostajh,

I made a bare module directory, a poor imitation of your git repo structure:

$ mkdir -p /tmp/client/sites/all/modules
$ pushd !$
$ tar xzf ~/Downloads/schemaorg-7.x-1.0-alpha2.tar.gz
$ vim schemaorg/schemaorg.module
:echo b:Drupal_info

I find that b:Drupal_info.CORE is correctly set to 7. In particular, omni-completion works. For example, I enter drupal_get_path<C-X><C-O> and the function template opens in a small scratch window. (See the screen shot in comment #4.)

With the attached patch, I added the line

let g:Drupal_dirs = {6: '/Users/benji/Sites/drupal', 7: '/Users/benji/Sites/dgd7/drupal'}

to my vimrc file. Now, when I edit the module file, the script finds an appropriate Drupal directory. It may be different from the one that is symlinked to the current git repo, but for now I do not see any disadvantage. I think the only way our scripts use DRUPAL_ROOT so far is to jump to tags. For example,

:stag drupal_get_path

works fine for me.

If this suits your needs, I will add some documentation under :help drupal-magic and commit the patch. (Or you could add the documentation.)

@kostajh, you are welcome! Thanks for testing.

I added a few lines to doc/drupal.txt and committed it: http://drupalcode.org/project/vimrc.git/commit/f0d2b12. The final patch is attached.

I must be tired. I forgot to mention this issue number in the commit message. :-(