In #1139034: Vim Plugins? I mentioned that we should consider other forks of SnipMate. According to @erifneerg on http://drupal.org/node/1389472, we should consider https://github.com/garbas/vim-snipmate.

In #1139034: Vim Plugins? I also mentioned that we should consider https://github.com/dahu/SnippetsBar, which lists the available snippets in a GUI menu.

After #1839780: Update installation script to download plugins it is quite easy to update the installation script to add and replace plugins.

Related issue:

#1839828: Update and add code snippets

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

benjifisher’s picture

Issue summary: View changes

Add related issue.

rodrigoaguilera’s picture

Issue summary: View changes

As quick way to make https://github.com/garbas/vim-snipmate work

I renamed snipmate to snippets inside the vim-plugin-for-drupal plugin and added this to my vimrc

let g:snipMate = {}
let g:snipMate.scope_aliases = {}
let g:snipMate.scope_aliases['drupal'] = 'drupal,drupal7'

the "drupal" scope is already loaded

benjifisher’s picture

Another option is to use UltiSnips: on vim.org and GitHub.

rodrigoaguilera’s picture

Title: Test different forks of SnipMate plugin. » Provide compatibility for the different forks of SnipMate plugin.

Yeah but the thing is that the snippets files are the same for all the plugins. I don't care much about what is the recomendation.

Let's change this issue to do some work.
drupal#BufEntr() should be modified to check if the plugins are present and make them know were the drupal snippets are.

Related:
https://www.drupal.org/node/2254703

benjifisher’s picture

@rodrigoaguilera:

This project has to make a recommendation of which fork to use. The project is aimed at users who are not familiar with customizing vim, and the drush vimrc-installl command will download the recommended plugins.

Being compatible with SnipMate (original and the garbas fork) and UltiSnips is a good idea. IIRC, the reason I did not use the standard snippets/ directory is that I want to set ft=php.drupal and we need a way to choose either the D6 or D7 (soon D8) snippets. Is that what the scope_aliases option does? I do not think it is supported by the original SnipMate.

rodrigoaguilera’s picture

he reason I did not use the standard snippets/ directory is that I want to set ft=php.drupal and we need a way to choose either the D6 or D7

I don't understand, there's no difference between naming the folder "snipmate" or "snippets". garbas' snipmate look in the folder "snippets" then collects a list of scopes from ft, namely php and drupal. then looks for "snippets/php/.*snippet" and "snippets/drupal/*.snippet". That's why I added drupal7 as an alias to drupal scope meaning "when you look for drupal snippets look also for drupal7 snippets".

The code that is in drupal#BufEntr() is kinda what garbas' snipmate does. We still need to set drupal7 as ft, scope or something (If I knew what I'm talking about I'll provide a patch)

I regard as a a good decision to provide the default snipmate from vimscrits.

Are you benjy on IRC ? your d.o profile doesn't say

benjifisher’s picture

We still need to set drupal7 as ft, scope or something

We currently set the 'filetype' option to php.drupal and I would rather not change it to php.drupal7. AFAIK, "scope" is only understood by the garbas fork of SnipMate.

I am benjifisher on IRC, but I rarely have an IRC client running. You can use my d.o contact form to send me an e-mail, and if you want I can arrange to have IRC turned on for a chat.

rodrigoaguilera’s picture

Assigned: Unassigned » rodrigoaguilera
Status: Active » Needs review
FileSize
36.5 KB

A patch to make the drupal snippets compatible with the more updated snipmate
https://github.com/garbas/vim-snipmate
while maintaining compatibility with the older one (recommended in plugins section)

benjifisher’s picture

Status: Needs review » Needs work

One of the comments needs to be fixed:

" garbas' snipmate is aware of version-indepent snippets but
" we need to load the scope for the version of Drupal.

We should capitalize "garbas" at the start of the sentence, and "indepent" looks like a misspelling of "independent", and I think it should really be "dependent".

I was worried that, after moving the snippets under the standard snippets/ subdirectory, SnipMate would load all of them instead of just the correct ones for the current version. This did not happen. :) For example, when editing a D6 module file, the hook_perm snippet was recognized, but not hook_permission; when editing a D7 module file, it was the other way around.

The patch conflicts with the one for #2133417: Add snippet support for text_format, but I would rather do a "git move" than apply a patch, anyway, so that is not a problem. You did not change the snippet files except to move them to the new directory, right? If that is right, then I will commit the patch if you just change the comment.

rodrigoaguilera’s picture

Comment rephrased. Garbas snipmate already loads the version independent but in order to load drupal 7 or drupal 6 snippets we add a new scope, better than scope_aliases.
Rerolled agains latest dev so it applies cleanly. Also used git move.

As side comment I corrected a couple of lines that had indentantion tabs different from the rest of the file but looks like the standard is indentation tabs for vim plugins. I exprerienced this auto indenting. What should we do in the future?

rodrigoaguilera’s picture

Status: Needs work » Needs review

benjifisher’s picture

Assigned: rodrigoaguilera » Unassigned
Status: Needs review » Fixed

@rodrigoaguilera:

Thanks for the clarification. I repeated the test from #8 just to be safe, committed and pushed. (The --index git flag is convenient.)

I have not been consistent myself between spaces and tabs. I do not think that there are explicit coding standards for vim script, so let's stick with the Drupal standards (:set sw=2 et) going forward.

rodrigoaguilera’s picture

Thanks :)
I'm don't know what the flag --index is.

benjifisher’s picture

The --index option is recommended when rerolling a patch (see Step 6). Curiously, it is not part of the standard advice for module maintainers; maybe it should be.

This option has the effect of staging all the changes introduced by the patch. In particular, it helps keep track of newly added files, which might otherwise be missed (depending on how many untracked files you have lying around). In #12, I mentioned it because it took care of recognizing that the files had been moved, not deleted and added. (I am still not sure how much of this is thanks to the information in the patch file and how much git is just being clever.)

Status: Fixed » Closed (fixed)

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