I am trying to set up omni completion for PHP in vim 7.3 with ctags 5.9~svn20110310 on Ubuntu 12.04.1 (LTS) but I am running into a very strange issue where completion provides radically different predictions for instances of the same class.
I have the following two files:
// Foo.php
class Foo {
public function do_stuff() {
echo 'Working...';
}
}
// index.php
require 'Foo.php';
$f = new Foo();
$f->[cursor position 1]
$g = new Foo();
$g->[cursor position 2]
When the cursor is in position 1 and I press CTRL+X CTRL+O it comples the line with do_stuff( as we would expect. But when I press CTRL+X CTRL+O in the second position I get a list of predictions that starts with key, next, rewind. What am I doing wrong?
Edit: With regard to your specific issue, if you have an old version of phpcomplete.vim, it's possible that you can only properly complete off a variable either by marking it with a special phpdoc tag (see this question) or by regenerating your tags file after declaring the variable.
In all probability, you are doing nothing wrong; the PHP support in ctags is extremely basic and not very rigorous, which unfortunately means the Vim support is lacking, too. A quick look at the ctags module illustrates the problem:
ctags/php.c
That's it. Just a couple of relatively basic regular expressions. That parser stuff at the bottom is not used any longer, and tragically hasn't been for a very long time.
Compounding the issue is the fact that the standard omnicomplete function for PHP in Vim is hackish at best; suffice it to say that it involves switching between all the open windows as part of its completion process (a practise explicitly condemned by Vim documentation). Take a look for yourself:
phpcomplete.vim/autoload/phpcomplete.vim
I have struggled with terrible PHP completion in Vim for a long time now and have determined that nothing short of a complete overhaul will produce a satisfactory result. I've joined the ctags dev mailing list, and I plan to improve the PHP support there before moving on to making Vim's omnicompletion thereof work as properly as it can in an interpreted language. For now, unfortunately, the solution is to wait until the support is better, or fix it yourself.
Related
I read somewhere that php parses the whole .php file every time it is executed. Some solution was proposed in there (that was not opcache), but I lost the website and I couldn't find it.
Now I have an enormous php website that has many long functions that are often used alone, and it's required that the execution be fast.
To avoid having php parsing all the other functions that won't be used, I was thinking of making a modular design in which the functions, stored in independent php files, will only be included if they will be actually used. But I haven't been able to confirm that php will not parse an include inside of a function or inside of a conditional statement unless it is required. Does php parse those includes?
Example:
<?php
$func_to_execute = $_GET['func'];
$parameter = $_GET['parameter'];
switch($func_to_execute)
{
case 'a':
include 'func_a.php';
$output = func_a($parameter);
break;
case 'b':
include 'func_b.php';
$output = func_b($parameter);
break;
case 'c':
include 'func_c.php';
$output = func_c($parameter);
break;
};
echo $output;
?>
In this example, I would like php to parse only the func_a if I am requesting a, only the func_b if I am requesting b, etcetera. There are in practice more than just 3 functions, and each is a very long algorythm with also very long strings and arrays.
As an alternative to includes I was thinking of making independent php files and execute them and retrieve their output only if they are required, with a shell_exec. But that would take other complexities, like formatting the parameters (I don't have idea of how I would pass a very long string with special characters, or a JSON, as a parameter in the shell) and calling the function to execute in the shell. Would those complexities make it slower than just letting php parse the whole file?
I know about the opcache function. Would it be enough even if all the ops of all the functions will be tested each time?
Are there other ways to make a PHP website modular, and not having php parsing the whole of php files everytime?
Thank you.
since php uses many optimizations and caching apcu i.e. you dont need to care about this
include wont be parsed at load time.. its more like file_get_contents and execute in same context - and these will be optimized by internal php cache
http://php.net/manual/en/intro.apc.php
I made a benchmarking experiment and it seems that php truly does not parse conditional includes. I made the test using the example script mentioned, and defining each as:
func_a: it only declares that the value of the variable $x is the sentence 'war and peace'.
$x = 'war and peace';
func_b: it only declares that the value of the variable $x is the whole text of the novel war and peace, which is approximately 3.2 MB long (the whole text was pasted in the php file). This would be a very long file to parse.
$x = 'War and Peace, by Leo Tolstoy...(the whole novel...)...';
func_c: it contained incorrect syntax, that should immediately launch an error message from php. This was made to guarantee that php was not actually parsing what was not included.
I measured the execution time from another php script with the function shell_exec(). The results were (in seconds):
func_a ≈ 0.122
func_b ≈ 0.152
func_c ≈ 0.119
Therefore I conclude that:
- Includes in a switch statement are not parsed unless they are actually required.
- A syntax mistake in an include (inside a switch statement) will not launch any error if it is not actually required, because it is not parsed.
- Anyway, the difference on the time of the process is very little (about 0.03 extra second for an extra text of 3.3 MB; or crudely said, 0.01 extra second per 1 MB of text to parse). However this might be important to consider if there are many users requesting the website at the same time, and therefore it might be useful to divide in modules (includes) if the script is actually that big. Also the fact that a wrongly written include that was not required be not parsed helps to not launch errors when they aren't relevant.
It seems then for me a good manner to design a modular application in PHP where the modules be extremely big.
I have the following PHP code snippet written in an attempt to use COM to access Crystal Reports XI (Version 14.0.4.738 RTM):
$ObjectFactory = new COM("CrystalReports14.ObjectFactory.1") or die("CR loading failed");
$crapp = $ObjectFactory->CreateObject("CrystalReports14.ObjectFactory.1");
$creport = $crapp->OpenReport($rptFile, 1);
...
The first two lines seems to be ok on the surface. The third line throws an error, however:
Fatal error: Call to undefined method variant::OpenReport() in ...
I am not 100% certain that I have done the CreateObject() call (second line) correctly; it seems oddly redundant that I am using the same string for the first line and second line. But maybe that's the way it is.
After searching on the web for quite literally 2 or 3 hours, I am starting to think that there is no documentation on this, but refuse to think that nobody has ever done this before! Does anyone have any experience with this?
Thanks in advance!
It is strange that you use ObjectFactory in the ProgID to create the COM.
Object factories, in COM, have a specific meaning and usually they are not applications.
I have found a question related to Crystal Reports and there they use a string that seems to me much likely to be the application ID. You should try it:
Crystal Reports & VBScript - Could Not Locate Automation Class
I am looking for a command-line tool that removes all comments from an input
file and returns the stripped output. It'd be nice it supports popular
programming languages like c, c++, python, php, javascript, html, css, etc. It
has to be syntax-aware as opposed to regexp-based, since the latter will catch
the pattern in source code strings as well. Is there any such tool?
I am fully aware that comments are useful information and often leaving them
as they are is a good idea. It's just that my focus is on different use cases.
cloc, a free Perl script, can do this.
Remove Comments from Source Code
How can you tell if cloc correctly identifies comments? One way to convince yourself cloc is doing the right thing is to use its --strip-comments option to remove comments and blank lines from files, then compare the stripped-down files to originals.
It supports a lot of languages.
What you want can be done with emacs scripting.
I wrote this script for you which does exactly what you want and can be easily extended to any language.
Filename: kill-comments
#!/usr/bin/python
import subprocess
import sys
import os
target_file = sys.argv[1]
command = "emacs -batch -l ~/.emacs-batch " + \
target_file + \
" --eval '(kill-comment (count-lines (point-min) (point-max)))'" + \
" -f save-buffer"
#to load a custom .emacs script (for more syntax support),
#use -l <file> in the above command
#print command
fnull = open(os.devnull, 'w')
subprocess.call(command, shell = True, stdout = fnull, stderr = fnull)
fnull.close()
to use it just call:
kill-comments <file-name>
To add any language to it edit ~/.emacs-batch and add that language's major mode.
You can find syntax aware modes for basically everything you could want at http://www.emacswiki.org.
As an example, here is my ~/.emacs-batch file. It extends the above script to remove comments from javascript files. (I have javascript.el in my ~/.el directory)
(setq load-path (append (list (concat (getenv "HOME") "/.el")) load-path))
(load "javascript")
(setq auto-mode-alist (cons '("\\.js$" . javascript-mode) auto-mode-alist))
With the javascript addition this will remove comments from all the filetypes you mentioned as well as many more.
Good Luck and happy coding!
Paul Dixon's response to this question on stripping comments from a script might be worth looking at.
I don't know of such a tool - which isn't the same as saying there isn't one.
I once started to design one, but it quickly gets insane - not helped by the comment rules in C and C++.
/\
* Comment? *\
/
(Answer: yes!)
"/\
* Comment? *\
/"
(Answer: no!)
To do the job reasonably, you have to be aware of:
Language comment conventions
Language quoted string conventions (Python and Perl are enough to drive you insane here)
Escape conventions (Shell gets you here - along with the quotes)
These combine to make the job tolerably close to impossible.
I ended up with a program, scc, to strip C and C++ comments. Its torture test includes worse examples than the comments shown above - and it does a decent job. But extending that to do shell or Perl or Python or (take your pick) was sufficiently non-trivial that I did not do it.
No such tool exists yet.
You might coax GNU Source-highlight into doing this.
I'm trying to debug a plugin-bloated Wordpress installation; so I've added a very simple homebrew logger that records all the callbacks, which are basically listed in a single, ultimately 250+ row multidimensional array in Wordpress (I can't use print_r() because I need to catch them right before they are called).
My logger line is $logger->log("\t" . $callback . "\n");
The logger produces a dandy text file in normal situations, but at two points during this particular task it is adding something which causes my log file to no longer be encoded properly. Gedit (I'm on Ubuntu) won't open the file, claiming to not understand the encoding. In vim, the culprit corrupt callback (which I could not find in the debugger, looking at the array) is about in the middle and printed as ^#lambda_546 and at the end of file there's this cute guy ^M. The ^M and ^# are blue in my vim, which has no color theme set for .txt files. I don't know what it means.
I tried adding an is_string($callback) condition, but I get the same results.
Any ideas?
^# is a NUL character (\0) and ^M is a CR (\r). No idea why they're being generated though. You'd have to muck through the source and database to find out. geany should be able to open the file easily enough though.
Seems these cute guys are a result of your callback formatting for windows.
Mystery over. One of the callbacks was an anonymous function. Investigating the PHP create_function documentation, I saw that a commenter had noted that the created function has a name like so: chr(0) . lambda_n. Thanks PHP.
As for the \r. Well, that is more embarrassing. My logger reused some older code that I previously written which did end lines in \r\n.
I'm working with the PHP CLI on windows at the moment to write some small desktop command-line apps.
I wanted to know if and how it may be possible to:
Clear the screen (cls would be the normal command but exec() won't work with it)
Change the color, change the color of parts of the output (seen this in programs before)
Make the command line horizontally bigger - things quickly get unreadable
Is any of the above possible from inside a PHP script?
On Windows, in the standard CLI prompt, you cannot output in colour (as in the answer by Spudley).
You can change the size of the window as a user by right-clicking the command window's title bar and selecting Properties, then ammending values in the Layout tab. I do not think it is possible to ammend the width of the CLI within PHP.
You can check the width of the CLI window on Windows using the function I wrote here
See the PHP manual page for working with the commandline
To directly answer each of your bullet points:
There is a comment on that page which gives a function that can clear the screen. I'll quote it here for you:
<?php
function clearscreen($out = TRUE) {
$clearscreen = chr(27)."[H".chr(27)."[2J";
if ($out) print $clearscreen;
else return $clearscreen;
}
?>
There's also another comment which explains how to change the colours. Again, I'll quote it:
<?php
echo "\033[31m".$myvar; // red foreground
echo "\033[41m".$myvar; // red background
?>
and to reset:
<?php
echo "\033[0m";
?>
You should read through the rest of that page for a whole load more suggestions on how to manipulate the CLI.
The only part of your question that leave unanswered is the third bullet point. Sadly, I don't believe you'll be able to do this, and I don't think it's possible to horizontally resize the Windows command line window.
Hope that helps.
I created a small backup script with PHP, and from what I can remember, you can print backspace characters to remove content. Not really ideal though.
Just google'd it: http://www.php.net/manual/en/features.commandline.php#77142
As far as the third question goes, I suggest you witch the default command line to Console 2. It is a great replacement that not only lets you use any width you like (as long as it fits your screen), but also supports command history, tabs, and some UI sugar.
The provided code will not work under Windows because PHP under windows does something to the command window. I am not sure what PHP does but I wrote a simple Freebasic program with only two lines:
cls
end
I then compiled it and ran it under a regular command line window. It cleared the screen without any kind of a problem. I then did the following in PHP:
<?php
echo "This is a test\n";
system( "cls.exe" );
exec( "cls.exe" );
passthru( "cls.exe" );
?>
When I ran the program it did nothing more than just the "This is a test" line. Thus, there is some kind of suppression going on with PHP that looks for and stops any kind of escape sequence from occurring. Until this is fixed in PHP - you will never be able to do a cls, nor use curses, ncurses, or any other library. What has to be done is to integrate something like FreeBasic's windowing methods as some kind of a class (or maybe just a C set of routines) that will open a new window via THAT language's methodologies and use them to do the text window. Then all of the escape sequences will work. Until then - they won't.
What I find weird about this is that PHP was originally written in Perl and Perl will do ncurses on Windows without any problems. Perl will also allow all escape sequences to work. So there is just something being done on the Windows compile that is causing this problem.