Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Coder modules has a script in /scripts/coder_format/coder_format.php which lets you run a file or directory through Code Review.
It would be nice to have a "Coder" and "CoderUndo" command as part of this plugin. Maybe take the output from coder_format.php and display it as a diff against the original file?
Comment | File | Size | Author |
---|---|---|---|
#12 | compiler-1328552-12.patch | 2.73 KB | benjifisher |
#11 | add_drupalcs_syntastic_support.patch | 2.98 KB | ethanw |
#10 | compiler-1328552-10.patch | 1.72 KB | benjifisher |
#3 | compiler-1328552-3.patch | 988 bytes | benjifisher |
Comments
Comment #1
benjifisherThis will run PHP in lint mode (syntax checking) on the current buffer:
See
:help quickfix
for details.We can write a compiler plugin to set 'makeprg' and 'errorformat' appropriately for code review. Maybe use "drush code-review". Then all you will have to do is
If you want to use Coder to generate a replacement file (or update a module to D7) then we could write a few plugins.
Do you know about vim's diff mode? It rocks.
or
See
:help diff-mode
for a full explanation or:help 08.7
in the users' manual.Comment #2
benjifisherSee also the Drupal Code Sniffer, http://drupal.org/project/drupalcs . This is being used in automated reviews of project applications.
Comment #3
benjifisherThe attached patch is a first step. There is still work to be done.
For starters, try
This will invoke the PHP compiler plugin included in the standard vim distro, then run it on the current file. Pretty much like what I suggested in #1 above, invoking PHP in lint mode.
See :help 30.1 for an introduction to using vim's quickfix mode in the users' manual, :help quickfix.txt for complete details.
Now, after applying the attached patch, try this. Edit a file, like mymodule.module, that is inside your Drupal directory, and make sure that the Coder module is installed inside the same Drupal installation. Then
should run coder_format.php, as suggested in the issue summary. Note that this is aggressive: it replaces mymodule.module with the processed version, saving the original in mymodule.module.coder.orig. Vim should warn you that the file you are editing has changed, and give you the option of loading the new version into the editing buffer. (The
:e!
line in the above snippet does this manually.)See :help 08.7 in the users' manual and/or :help diff.txt for details on vim's diff mode. As I said in #1, it rocks.
Untested, but these should also work:
The last two run coder_format.php on the current directory and on the directory of the current file, respectively. The script coder_format.php knows what to do when given a directory rather than a file.
If you like this approach, here are some ideas for improving it.
Comment #4
kostajh CreditAttribution: kostajh commentedAlong the lines of point #3 above, would it be possible to manually specify the path to Coder (or coder_format.php)?
For example, perhaps in drushrc.php (~/.drush/drushrc.php) we could have an option $options['coder-path'] = "~/.drush/coder/coder_format.php". Or there could be an option to use wget/curl to download coder_format.php and place it in the users .drush directory?
Comment #5
benjifisher@kostajh, tell me more!
I did suggest using drush in #1 above, but I have not tried it yet. That would be one way to use drushrc.php for customization: use drush in the
'makeprg'
setting, instead of calling php directly.Did you have something else in mind? Perhaps one of our vim scripts could parse drushrc.php for some information. Probably is is better to let drush do the work.
Comment #6
benjifisherP.S. Maybe you can help me avoid some RTFM. I am still a drush newbie, using only "drush dl", "drush en", and "drush up". Until today, I did not have a drushrc.php. I tried creating ~/.drush/drushrc.php with the following line (after an opening php tag):
but I think I need to do something more to tell drush where to find the coder-review command. Probably something similar. (If I am editing a module inside my D7 installation, where Coder is installed, it works fine. I am trying to figure out how to get it to work inside my D6 installation.)
In short, I have not yet figured out where to look for drush documentation. :-(
Comment #7
kostajh CreditAttribution: kostajh commented@benjifisher - you can go to ~/.drush and type `drush dl coder` which will install coder for you 'globally', but the problem is that Coder requires a Drupal bootstrap to run, so `drush coder-review ~/path/to/example.module` won't work unless `~/path/to/example.module` is within a Drupal directory.
This is why I think using DrupalCS might be a better option for this project.
The best place for Drush documentation is in the examples sub-directory in drush. You can also check out drush.ws.
Comment #8
kostajh CreditAttribution: kostajh commentedBy the way, just came across this helpful guide to DrupalCS/Vim: http://echodittolabs.org/drupal-coding-standards-vim-code-sniffer-syntas...
Comment #9
benjifisher@kostajh:
Thanks. Now I understand why you used the path
~/.drush/coder/
in #4 above.I installed Coder "globally" as you suggested (#7), and I am making progress:
I am inside a Drupal directory:
(Don't worry, this is just my development server, not a live site!) As I said, Coder is already installed in my D7 directory, but not here. Still no success:
(Module name edited to maintain a suitable level of paranoia.)
It seems odd that the coder_review module has to be enabled for this to work, but that seems to be the way it works. I had to run
drush en coder_review
in my D7 directory to get it to work.I already suggested drupalcs in #2 above. I agree, it has a lot of advantages, especially if we can get it installed automatically with our installer, #1145580: Add installer?. There must be something very funky about the way PEAR got installed on my Mac, because I had a lot of trouble installing PHP_CodeSniffer.
Thanks for the tips on drush. The example drushrc.php looks useful, and the sample scripts will help when I am ready to try scripting. I still need something more basic. Last time I checked, drush.ws was overwhelming.
The blog post you mention reminds me that I should have a look at the syntastic plugin. Also git submodules. Although it looks as though Syntastic added support for phpcs in version 2.1.0, about a week ago, so maybe it is just as well that I waited.
Comment #10
benjifisherHere is a new version of the patch. Once we commit it, I will add further options for compiler settings and Syntastic support.
First, please test as in comment #3. I think that options relying on the Coder module, or anything that involves bootstrapping Drupal (such as
drush code-review
orCoder upgrade
) should follow this model, using:make
or:lmake
or some variant.Next, install Syntastic, phpcs (executable), and Drupalcs. Follow the instructions for symlinking the DrupalCodingStandard directory to the CodeSniffer/Standards directory. Then phpcs should run automatically each time you read or write a buffer. If necessary, introduce some violations of coding standards, like two spaces after an operator, and try
Since phpcs is fast, it is appropriate to use with Syntastic. We can also provide a compiler plugin so that it can be used without Syntastic.
Of course, if you can test only one or the other, please do. Maybe someone else will do the other test!
Comment #11
ethanw CreditAttribution: ethanw commentedI've opened a separate issue, #1460614: Add support for DrupalCS Syntastic Code Checks, for the Syntastic integration. I think there is now a better solution for that piece than I posted in the original blog article.
Original version of this comment below, for archive's sake. Removed due to the topic of this ticket being Coder support, not Syntastic/DrupalCS.
Syntastic now supports multiple filetype checking, so we can add a drupal syntax checker directly w/o needing to modify any global variable settings. The attached patch adds a filetype-based syntax checker for all files with ft=drupal (this may need to be adapted for css.drupal files!), without requiring any additional vimrc configuration. It should work out of the box on any machine with syntastic and drupalcs installed. I think this method is superior to the one in the referenced blog post...I'm going to post and update to the post with this recommendation.Note that this does not include compiler support. I don't personally use compiler and don't think syntax checking should depend on it's being installed, but I might be misunderstanding. Perhaps that can be bundled as a separate patch?
Comment #12
benjifisherI have committed (134180a) the attached patch, which includes the one from #10 and adds documentation. See
:help drupal-coder
. (Remember to run:helptags
or:Helptags
after applying the patch.)Like the patch from #10, this adds suport for the Syntastic plugin. I have not added any documentation to the vim help file, but I will add some to the documentation pages for this project. I also updated the title of this issue to reflect the Syntastic support.
Comment #13
benjifisherI forgot to commit the documentation and the Syntastic support. New commit: 5be8c6b.