Pull request to comment php check#37
Conversation
A recent update has broken fucntionality for me on two machines in the last week: user esseguin identified the commented lines as the source. I've not made any major changes to re implement the check as I'm not sure what the check was there to achieve, this serves more just to bring the issue to your attention. See issue: joonty#36
|
I've just stumbled across the vim docs here: http://vimdoc.sourceforge.net/htmldoc/eval.html#feature-list Far as I can tell, "php" isn't a valid feature to test for. Unless those docs are out of date. @hachreak was the guy that put in the check in the first place? If you see this can you please respond, I'd be interested to know what you were trying to do/ where you got your test from. Are you working with a specific distribution/ fork of vim? |
|
Hi @chrisRidgers, I found this kind of solution looking inside pymode |
|
Maybe this is better? if !executable("php")
finish
endif |
|
That appears to have worked. According to that list, "python" is a supported feature of Vim that can be supported. Vim plugins such as ctags / exuberant ctags make use of it. I've pushed a commit with your suggestion, it works on my mac, I'm sure someone else should be able to confirm. Thinking about it though maybe it would be better that a user receives that error? That way they know somethings wrong/ needs configuring if they want to use the plugin? |
|
I have a unique vim configuration for every computer and this can be a tedious error if I need to open a php file but I don't want install php. |
|
Can the solution be to not install the plugin as part of your unique vim configuration for those computers? Each approach is valid: I just think it potentially opens the doors for: huh, I installed this plugin but why isn't it working, type issues. |
|
It means for me to maintain 2 different configurations... not the best solution in my case. If in your system is not installed php, I think the plugin should be enough smart to disable itself without necessary remove it. |
|
Ah I see what you mean. I thought you meant you had a unique configuration for each individual computer. I guess it's fine for now, maybe a better idea would to do the same check in the .vimrc file? I'm not sure what the exact syntax would be though. |
Indeed. I'm a brand new user of this bundle and I just ran into this problem. I'm running Ubuntu 14.04.03 LTS and this PR solved my issue. |
|
I've been thinking about this in my head today: the ideal solution for me would be a variable set like: let g:phpqa_disabled=1In your .vimrc, combined with the proper syntax for checking php availability. So something like: if !executable('php')
let g:phpqa_disabled=1
endifBut I'm not up to scruff to implement that variable quickly into the plugin or even sure if the above is indeed the correct syntax for .vimrc for checking for php availability. But if that variable defaults to off, it gives guys like @hachreak the ability to stick the test in their .vimrc and forget about it, but it would appropriately kick out an error by default when it can't find php (as it currently does). |
|
Is there a way to get this merged that I'm not aware of yet? |
|
Yep! It involves me coming back off holiday, which has now happened Thanks for the PR, much appreciated. |
Pull request to comment php check
|
Sweet cheers. Anywhere nice? |
|
Ah the perfect coding environment. When in doubt, administer all pull requests from inside Space Mountain. |
|
They actually have free WiFi all over their parks, so I think it's actively On Wed, 30 Sep 2015 17:15 Chris notifications@github.com wrote:
|
|
Unlike the UK where a decent public WiFi costs you an arm, leg, best friend, soul, and 3 months of your life for every 10 minutes browsing. Any thoughts on: if !executable('php')
let g:phpqa_disabled=1
endifSomething like that likely to make a release in the future? |
|
Sure, I'll look at getting that in the next release. Thanks! On Wed, 30 Sep 2015 17:23 Chris notifications@github.com wrote:
|
|
Great, should keep @hachreak happy :) |
The commented lines are breaking plugin functionality on OSX w/
homebrew vim installs. Can confirm on two separate machines.
See issue: #36