Syntax highlighting for .info and .make files

I made some tweaks to the original file, added a TODO syntax and highlighting group.

Forgot to add a contains statement.

You should update the header. We want to use it for *.info and not *.ini nor the others. Peter Hosey does not want to maintain a Drupal-specific file.

" Vim syntax file
" Language:	Vim 7.2 script
" Filenames:    *.ini, .hgrc, */.hg/hgrc
" Maintainer:	Peter Hosey
" Last Change:	Nov 11, 2008
" Version:	7.2-02

Drupal info files only allow "=", not ":", I think, so these lines can be simplified:

syn match   iniRule "^[^=:]\{-1,}="
syn match   iniRule "^[^:=]\{-1,}:"

Does Drupal allow "#" for comments or just ";"?

syn match   iniComment skipwhite contains=iniTodo "^[#;].*"

I agree that it makes sense to use "ini" as the name of the syntax, but we might prefer to use "info".

let b:current_syntax = "ini"

The autocommands can go in .vim/ftdetect/drupal.vim so the user does not need to edit his or her vimrc file. See #1140306-5: Play nicely with other uses of Vim.

Despite my dislike of DOS, a much simpler solution is to use the "dosini" syntax file that is part of the standard vim distribution.

:set filetype=dosini

According to http://drupal.org/node/625094, drush make files may have extension .build as well as .make. (Did you have something else in mind for .make?) To be on the safe side, we can restrict the autocommands to recognize .info files only if they are under a modules/ directory. Is there any similar restriction for drush make files?

This has been committed as part of #1140306: Play nicely with other uses of Vim.

Thanks!

There's now a GitHib repo for the files. https://github.com/nielsonm/Vim-Drupal-7-.info-syn

Is this an improvement over the syntax/dosini.vim file in the standard vim distribution?

It's an improvement on a different vim file. The dosini.vim file would have been another starting point, but this file is based off of a more basic ini.vim syntax file.

I did not know about the dosini syntax, either, until I looked for it.

:e $VIMRUNTIME/syntax
/ini

I already added

" info and make files use INI syntax.
  autocmd BufRead,BufNewFile *.{info,make,build}  set filetype=dosini

to ftdetect/drupal.vim. That is why this issue was marked as closed in #6. (Notice that we are no longer putting everything in a single vimrc file.)

I am changing the status to "needs work." If you want to make improvements such as the ones suggested in #10, we can certainly define a new filetype (drupal-info or maybe drini ...). Then we could include your syntax file. (That is one of the advantages of not putting everything in one file.)

Here is an offer. If you can think of any features you would like to see implemented in an ftplugin for .info files, then I will implement them. If we have both an ftplugin and a syntax file, then it makes more sense to define a new filetype. So far, the only content in the ftplugin/dosini.vim included in the standard vim distro is

setlocal comments=:; commentstring=;\ %s formatoptions-=t formatoptions+=croql

I generally shy away from syntax files, but I suggest you have a look at the one for dosini. IMHO, it has simpler regexp's than yours.

I would still like answers to my questions in #5.

Another suggestion: if you add some keywords to the syntax file, then I can add

setlocal omnifunc=syntaxcomplete#Complete

to the ftplugin file, and we will have auto-completion of keywords.

:help ft-syntax-omni

In fact, adding keywords would be a big improvement, because then you could highlight "core" as a keyword but leave the misspelled "nmae" uncolored in

nmae = "Example module"
description = "Gives an example of a module."
core = 6.x

This is a work in progress, but it already works pretty well.

" TODO:  strict checking for the name, description, core, dependencies lines.
" TODO:  How do we recognize a Profiler ini file?  For now, Profiler includes
" all syntax items, which may be the right thing to do anyway.

Please test and let me know if anything is not working. Except for syntax-based autocomplete, which seems to be broken. :-( Let me know if that is working (and your version of vim).

The name of the filetype is still open for discussion. I am working with drini: the "dr" as in "drush" and the "ini" as in "dosini", for example.

The point of my first TODO item is that certain things should be flagged as errors according to the Drupal coding standards, such as a name that does not start with a capital or a description that is not a full sentence. Dependencies can include version restrictions.

" References:
" - modules (7.x):  http://drupal.org/node/542202
"   modules (6.x):  http://drupal.org/node/231036
"   themes (6.x, 7.x):  http://drupal.org/node/171205
"   format (7.x):
"   http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_parse_info_format/7
" 
"   format (6.x):
"   http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_parse_info_file/6 

Here is an updated version of the patch in #14. I am marking it "needs review" in the hope that someone will give it a spin, even though it still needs work. Syntax-based omnicomplete is still broken.

I rearranged the code in the hope of making it easier to follow. I fixed it so that something illegal like "7.9" will get no color in a line like

core = 7.9

I also fixed it so that a dependencies line like

dependencies[] = "example_api (>1.0, <=3.2, !=3.0,)"

will have the version restrictions get WarningMsg highlighting. Depending on your color scheme, this may or may not stand out.

One reference in addition to those in #14:

"   Profiler:
"   http://drupalcode.org/project/profiler_example.git/blob_plain/HEAD:/profiler_example.info 

If anyone wants to help with this, I have some questions:

1. How do I recognize a Profiler info file? What extension does it have; what directory is it under?
2. Feel free to suggest highlight groups that I should use.
3. According to http://drupal.org/node/171205#base-theme, we specify a base theme with something likebase theme = garland. Is this right, or do we just use "base" instead of "base theme"?

How do I recognize a Profiler info file? What extension does it have; what directory is it under?

My two cents, I don't think we should try to add Profiler support. It is an edge case and probably not worth the time.

According to http://drupal.org/node/171205#base-theme, we specify a base theme with something likebase theme = garland. Is this right, or do we just use "base" instead of "base theme"?

It should be "base theme". Thanks!

Well, Profiler support was requested in #13 above and I already added it. It just defines a few extra keywords, so it should not hurt when editing other .info files.

Thanks for confirming that "base theme" is correct. The current version should work correctly.

As I said in #14, the syntax-based autocompletion is broken. I wrote to the author, and he sent me a new version for testing. As soon as he uploads version 8.0 (or later) to http://www.vim.org/scripts/script.php?script_id=3172 you can grab that version, put it in ~/.vim/autoload/ and then

dep<C-X><C-O>

will auto-complete to "dependencies".

Don't you love how responsive open-source developers are?

This version improves handling keywords ("core", "dependencies", etc.) when they are not the first word in a line.

I am getting better at git. I now have a branch for this issue.

Question: Which takes precedence, that strings can span lines or that ';' in the first column starts a comment line? In other words,

description = "I am bored.
; Is this a comment?
Are you bored?"

I think this version is ready to commit. I just need someone to review it.

Changes since the previous patch:

1. Simplify by removing unneeded syntax clusters and making all key words driniKey.
2. Better way to deal with the "base theme" key in theme .info files.
3. More keywords for themes. See #1243144: 'regions_hidden' attribute in theme .info file not documented and my comment there.
4. Improve the behavior in case we do not know whether it is for a module, a theme, or drush make.
5. Strict checking for name and description values.

By experiment, the answer to my question in #19 is that ";' does not start a comment if it is inside a string. Luckily, that is the way it is highlighted. (No change from previous version.)

Try installing this and open up your favorite .info file: Bartik, Corolla, Views, http://drupalcode.org/project/profiler_example.git/blob_plain/HEAD:/prof... . IMHO it works great.

This is working wonderfully for me! Great work @benjifisher.

Thanks, skottler.

Would you mind testing one more version? This should work just the same. I rearranged the code and added some comments. I hope it makes the file more readable, thus easier to maintain. (Rearranging vim :syntax commands can be tricky. I think the changes I made are safe.) I also changed some whitespace, removing hard tabs and lining up keywords.

I have also attached a patch to autoload/syntaxcomplete.vim. (Credit goes to David Fishburn, author of the script.) In order to test autocompletion as described in #18 above, get version 7.0 of the script from the URL in #18 and apply the patch with

patch /path/to/syntaxcomplete.vim path/to/syntaxcomplete.patch

and put the patched script in ~/.vim/autoload/. (If you have vim 7.3, then you already have version 7.0 of syntaxcomplete.vim in your distro autoload directory.)

Update: As of late 2012, version 10.0 is available from the URL in #18.

Actually, do not test just yet.

I looked into it some more, and I see that drupal_parse_info_file() (D6) and drupal_parse_info_format() (D7, D8) will accept almost anything as a key name.

Other themes and modules can add their own keys. For example, both the Zen theme (at least the D6 version) and the Conditional style module add the keyword conditional-stylesheets. So I should allow almost anything.

Putting the keywords into the syntax file (as I already did) does have two advantages. First, it allows auto-completion with <C-X><C-O>. Second, it allows special checking for certain keywords. For example, I was looking at the codefilter module and I wondered why "Filter" was not highlighted in

name = Code Filter

Then I realized that the uppercase "F" violated coding standards. Boy, do I feel smug.

I realized another thing from looking at the functions that parse info files. A semicolon (";") starts a comment if it is the first non-blank in a line (and not inside a string). It does not have to be in column 1. The D6 version of zen.info has many lines that start ;, so I think the documentation should be changed to match the code, not vice versa.

The attached patch addresses the issues I raised in #23 above. Please test it.

Try using strings for the right-hand side. They can span multiple lines.

Try funky things line putting the "=" on a separate line.

Test autocompletion as described in #18 and #22 above.

In short, try to break it. If you cannot, then I will commit the patch. :)

By the way, here are some things I noticed.

First, base theme is a valid key. I believe that base theme (two spaces) is also valid, but would not be recognized as the same. It would be real hard to catch such a mistake, so maybe the syntax file should help you out. I want to move on, though.

Second, "foo \" bar" is a single string. Good. But so is "foo \\" bar". At least, I think that is how it will be parsed. I believe that my syntax file is just as lazy as the code base on this point.

@jessehs, thanks for testing.

Here is a version that solves the problem with dependencies (#26). I also noticed some oddities with description, and it deals with them better. (If you see something odd, try redrawing the screen with <C-L>.)

While I was working on it, I had the same idea you mentioned in #27. I think I had all keys, core or custom, highlighted the same. Now they are different. For example, features will be highlighted as core in a theme file and as custom in a module file. (If vim fails to decide whether it is a theme or module file, then it will be highlighted like core.) I also changed the color for brackets.

Did you try the autocomplete feature?

Feel free to suggest other highlight groups from the ones I chose.

Jesse,

I am inclined to leave in the autocomplete feature. It is a single local option set in ftplugin/drini.vim:

setl omnifunc=syntaxcomplete#Complete

By itself, this is pretty harmless. The tricky part is patching autoload/syntaxcomplete.vim, which is part of the standard vim distribution. I do not intend to do that automatically, just make the patch available on this page.

It may be several days before I have time to update the documentation and commit the patch, so there is still time to convince me otherwise.

I updated README.txt and doc/drupal.txt. I also rearranged the comments in ftplugin/drini.vim. Other than that, this is the same as the patch in #28. In particular, I left in the 'omnifunc' setting, as I said in #30. In a minute, I will commit this patch to the project.

I forgot to mark the issue as fixed.