Similar project phpctags which uses nikic's PHPParser as tokenizer

[weynhamz]

I have created a project called phpctags almost the same time as this project, but using a different approach, please give it a look. It might be good to join our effect.

[EvanDotPro]

@techlivezheng nice! I'll take a look at this. Indeed there's no reason to have two projects. If yours is further along, I'm happy to focus any development efforts there.

I had been thinking we could use the vim-php GH organization to centralize projects like this that make VIM a better tool for PHP development, as well... Just a thought. @shawncplus has a very nice, updated version of phpcomplete.vim as well that could fit into a collection of tools / vim scripts for PHP development.

[weynhamz]

@EvanDotPro I like the idea, and I am happy to add my phpctags and tagbar-phpctags vim plugin to vim-php GH organizaion, and let more get involved.

[EvanDotPro]

@techlivezheng that sounds great! What I've done is made you a fellow owner in the vim-php organization, so you have the same permissions as me. If you move the repos into the organization, what I'll do is update my phptags repo to simply point to your updated, maintained phpctags project for some time (in case people have it bookmarked, etc), and maybe eventually we'll just drop it.

I think it'd also be worth speaking with @shawncplus and maybe a couple others who have built some great Vim/PHP plugins and tools to see if we can make this organization a central place for people to find the most up-to-date and maintained PHP toolset for Vim. :smile:

[shawncplus]

I've no objections against having a centralized place for things like this

[EvanDotPro]

@shawncplus Awesome! I'll go ahead and add you as an owner on the organization, too, which should allow you move projects into the organization if you want (GitHub now redirects from the old URL which is awesome).

We can work out how we want to assign repository/organization permissions. It might be worth setting up an IRC channel for this, or maybe just hijacking #vim temporarily. :)

[weynhamz]

@EvanDotPro Repos moved.

How should we name our vim plugin repositories? I have a own convention of naming repositories, but as it's now an org project, I think it should be named in a more common manner, maybe vim-tagbar-phpctags or tagbar-phpctags.vim. Anyway, the naming should be persistent for all vim plugin repos in the org.

[EvanDotPro]

@techlivezheng I agree, we should come up with and follow a convention. I've seen both styles (vim-xyz and xyz.vim), and I'm not really convinced that either is better than the other. Interestingly, some plugins like fugitive have a repo name vim-fugitive but then the plugin name in the readme is fugitive.vim.

If @shawncplus plans to move over phpcomplete.vim to the org, maybe we should just follow the xyz.vim naming convention, since that is a project that is pretty well established, so it definitely wouldn't be a good idea to rename that one.

PS: I made the organization a gravatar. ;)

[weynhamz]

@EvanDotPro Yeah, xyz.vim is fine, it is actually the original vim plugin naming convention. The gravatar looks good.

[EvanDotPro]

@techlivezheng cool, sounds good!

[tomphp]

I really like the idea of @techlivezheng's project but I've just tried switching and it's taking far to long to build.

I can't seem to get it to finish building tags for a project which uses Zend Framework 2 and Doctrine 2. I will try again when I have more time for but now I'm going to have to continue using this one.

[weynhamz]

@tomphp There has been a PR about the performance improving, hasn't get the chance to test it, maybe you could give it a try. See vim-php/phpctags#23.

[tomphp]

@techlivezheng I've just given the PR a try and here are my findings:

I ran the various versions of phpctags & phptags on the library folder of the Zend Framework too code. This folder is about 16mb and contains about 2258 PHP files.

First I ran phptag with the following command:

phpctags -h ".php" -R --sort=yes --tag-relative=yes --fields=+aimS --languages=php vendor/zendframework/zendframework/library/

Time taken: less than 1 second Tag file size: 4076777

Next up I ran the current master of phpctags with the following command:

~/Build/phpctags/phpctags -R -f tags vendor/zendframework/zendframework/library/

Time taken: 4min 7seconds Tag file size: no tag file created (?)

Finally I ran phpctags with the performance PR:

~/Build/phpctags/phpctags -R -f tags vendor/zendframework/zendframework/library/

Time taken: 34 seconds Tag file size: 7408584

Conclusion & Thoughts

The good news is the PR has made a really good improvement and makes it much more usable. I've not looked at the tag file itself but I wander why the phpctags tags file is almost twice the size. Maybe it's doing a better job than phptags?

I'm actually a bit unsure how the phptags one manages to do it in under a second but the tags seem good, my autocomplete, linking and namespace resolving plugin works well (I don't have tagbar installed).

All in all the PR is a great improvement but it's still quite a wait if you have to run it when creating a new class or something. Saying that maybe I need to look into getting it to build in the background.

[weynhamz]

@tomphp Thanks for your comprehensive report.

phpctags currently use absolute path in the tags file, that's why the size is almost twice, changing it to relative path is on the plan.

phptags and phpctags use different tokenizer, phptags seems using Zend's tokenizer, which might be better in performance,just a wild guess, will run some benchmarks someday, and see if it is possible to use Zend's tokenizer as an alternative backend.

The performace is definitely the next major issue.

[mr-russ]

Given the Moodle sources scan went from 60 minutes to 5 (12x faster) I would expect my pull request to bring performance in line with phptags. The additional cache file adds another order of performance to allow multi-branch and very fast updates on large code bases. Fast enough to be in a git hook and nearly fast enough to run on save in vi.

Further improvements for file save can be made by allowing incremental updates using the cache file. I believe performance can be made fast enough to have as a vim save script.