Closed (fixed)
Project:
Vim Plugin For Drupal
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
26 Apr 2011 at 17:04 UTC
Updated:
4 Nov 2012 at 17:31 UTC
Jump to comment: Most recent file
Comments
Comment #1
theunraveler commentedI already have some Drupal snippets for snipMate. It really needs to be updated for D7, but I accept pull requests!
https://github.com/theunraveler/Drupal-Snippets-for-Vim
Comment #2
skottler commentedIf we were to implement a plugin, as discussed in #1140306: Play nicely with other uses of Vim, we could also implement snippets as a part of that process.
Comment #3
grndlvl commentedHere is a script that looks @ drupal / modules to generate SnipMate snippets for all functions.(not hook_implementations)
https://github.com/grndlvl/drupal-snippets
Does some code expansions for some functions.
I am planning on adding overrides etc..
** Note ** File type must include drupal
Comment #4
kostajh commentedFiletype needs to be set to 'drupal' for the snippets here https://github.com/theunraveler/Drupal-Snippets-for-Vim to work with this plugin.
Attached patch adds a 'drupal' filetype in addition to the php filetype that is already defined for Drupal files.
Comment #5
benjifisherPardon me while I wipe the egg off my face.
I did not realize that
worked that way. I thought it was creating a new filetype. I just checked, and this was added in vim 7.0.
This will make things simpler. Too bad I have other things I have to do today.
Has anyone tested these snippets?
@theunraveler, if you are paying attention to this issue, can we include your snippets in this project?
Comment #6
theunraveler commentedFeel free.
Comment #7
kostajh commentedIt's okay I didn't realize setting filetypes worked in that fashion either until today :)
Regarding the snippets, if we add them to this project we should consider re-organizing them. In Textmate there was a concept of setting a variable for DRUPAL_API to 6 or 7 (https://github.com/psynaptic/php-drupal.tmbundle). The snippets would then reflect which API version a user had specified in their preferences.
Perhaps we could reorganize the snippets in 'drupal6' and 'drupal7' directories (currently there is just a 'drupal' directory in theunravelers project). Users could specify `drupal_api` in their vimrc and/or there could be a simple command ("DrupalAPI") to quickly switch when editing a file? What do you all think?
Comment #8
benjifisher@theunraveler,
Thanks. I am actively working on other things, but I plan to try out your snippets and add them to the project, unless someone else beats me to it.
@kostajh,
I committed your patch from #4. You and I may have just learned about what
set ft=php.drupalmeans, but deviantintegral already suggested it in #1140306: Play nicely with other uses of Vim. Part of my comment in #5 on that issue was misguided.Now that I have committed the patch from #4, I can simplify the changes in #1328290: Add suppport for javascript and other file types..
Comment #9
benjifisherOK, I had a look at snipMate.vim. This definitely looks like a good addition to the project, but I plan to make some changes.
First of all, the snippets I have looked at (comment #1 above) are only useful when editing PHP files. Instead of including them when editing any Drupal file (where this project sets 'ft' to "php.drupal" or "css.drupal" etc.) I think we can include them selectively with
ExtractSnipsFile()orExtractSnips(). At the same time, we can decide whether to use snippets appropriate for D6, D7, or D8. (I do not intend to support D5 in this project, but patches are always welcome.) This is like the suggestion in #7 above, but we can useb:Drupal_info.COREto automagically use the right version instead of asking the user to set a variable.Second, the hook snippets use snipMate's
Filename()function. This works well since hook implementations usually (always?) go in the .module file. In other contexts (include/pages.inc or mytheme/template.php, for example), we can usefnamemodify(b:Drupal_info.INFO_FILE, ':t:r'). (I have not yet tested this in a snippet.)Third, there are several collections of Drupal snippets out there. See comments #1 and #3 above. Also the summary of #1139034: Vim Plugins?. The page on configuring vim (http://drupal.org/node/29325) mentions http://github.com/blup/snippets, and I forget where I found https://github.com/agileadam/drupal6snipmate. It would be great if we could combine forces to get a comprehensive collection of Drupal snippets. I see that @kostajh has already contributed to @theunraveler's collection, so I am inclined to start there.
Any comments on using a lot of small .snippet files instead of a few large .snippets files?
Fourth, I am wondering how best to add files to this project. More generally, how do we get GitHub.com and d.o to work together smoothly? I could simply download the current version, rearrange to suit the needs of this project, and occasionally do it again as snippets get added. Or I could study the git docs on submodules.
Fifth, a question. The PHP snippets that come with snipMate.vim give me this array snippet:
Does anyone have a multi-line array snippet, with a convenient way to add more rows?
Comment #10
benjifisherThe attached patch is my first attempt at supporting SnipMate. It took me a while to figure out the
ExtractSnips ()function. :-(There is another complication. Snippets are not local to the buffer, so if you edit files from two different versions of Drupal in the same session, you have to be careful. (For example, you might open a D6 module, run Coder Upgrade, and then edit the D7 module you just created. See #1328552: Add support for Coder code reviews and Syntastic plugin for some ideas on this.) I solve this by telling snipMate.vim that our snippets belong to filetype "drupal" and resetting them each time we enter a buffer. Our script already redefines
$DRUPAL_ROOTat the same time, so I bundled these changes in a function.I adopted the following directory structure. If you want to propose a simpler alternative, speak up now, before it gets committed to the project!
We can add snippets for other versions of Drupal and other file types (CSS, javascript, etc.) in the obvious way.
Note that I support both .snippet and .snippets files. We can change our minds about which to use, or use both, without making further changes to filetype/drupal.vim. It will simplify my commit logs if we use a few .snippets files instead of a lot of .snippet files. I still want to hear other opinions on which organization to use.
For testing purposes, I took all of @theunraveler's snippets (comment #1 above) and put them under drupal/, then moved all the hook_*.snippet files to drupal6/. I defined one snippet,
foo, in drupal/php.snippets.There is still a lot of work to be done, but I would appreciate testing at this point.
Comment #11
grndlvl commentedDuring testing I have found that a single .snippet file gave better performance. This is only based on the work I had done with running a script over drupal core to create snippets @ first I was creating individual snippet files and with the amount of snippets that were created Vim would not even load within a reasonable time, but I have since stopped using the snippets that were created automatically b/c the single file that it now creates is simply unnecessarily too big and Vim takes too much of a performance hit. In other words too many files OR too large of a file will cause performance issues with Vim. But, as I said I found a single file to do a bit better than multiple smaller .snippet files.
Comment #12
benjifisher@grndlvl,
Thanks for the input. I am not surprised that the overhead of opening a file outweighs having to read a few extra characters (the "snippet trigger" line) per snippet.
When you write,
I assume you mean " a single .snippets file".
Is it still worthwhile for me to look at the collection you mentioned in #3, or is that too darn big?
Comment #13
benjifisherThis patch is now ready for testing. I made a serious attempt at dividing snippets up into the appropriate subdirectory of
snipmate/: one ofdrupal/,drupal6/, ordrupal7/.Following comment #11 above, I used one .snippets file instead of lots of .snippet files. Another (small) advantage of this approach is that I can arrange the snippets into logical groups and add a few comments.
If this patch passes testing, then the only work left will be to add more snippets.
Comment #14
benjifisherThe patch in #13 conflicts with some recent commits, so I am attaching an updated one.
While I was at it, I removed some trailing white space from some of the snippets.
Comment #15
benjifisherI have been waiting too long for someone to review this. I have committed it: 502c140. I have attached the final version of the patch.
Comment #16
benjifisherI forgot to mark it as fixed.