This week was meant for a bug fixing, some cleaning-out and organizational work. I fixed a few important problems. I started with modifying the PhpServlet of Orion PHP Editor server-side bundle and PhpContentAssist.js on the client side to make it communicate by POST and not GET requests, as sending PHP script as a GET parameter could work for testing, but would most probably soon incur some problems with URL length for bigger scripts.

Then next problem I wanted to solve was related to the fact that the content assist feature from PDT returns a huge list of all available proposals (all global functions, constants, etc) if you invoke the assistance when no prefix is available (for example, right after the semicolon, or at the very beginning of the script, etc). This big list loads for too long, and isn’t also very usable. I did some analysis of PDT API and I couldn’t find any suitable solution to this problem. For example, a method acceptContext() of interface CompletionRequestor should be called before each set of proposals from particular category (for particular context) is returned, but somehow it isn’t. I don’t know if it’s PDT or DLTK fault, I didn’t dive that much to get clear view of this problem. I asked on pdt-dev mailing list. I received a reply very soon, and Roy told me that it’s pretty much not possible to make PDT not return the full proposals list in such situation, except by doing some filtering.

At first I tried to get flags for a proposal and check if it’s a method (declaration or reference), but again, something seems to not work here as these flags are not being set for methods. But I shouldn’t really comment on the API as all that stuff is from internal package. So I went with the simple solution. After 100 first proposals, the
findParameterNames() is not called any more (as it’s a costly method), and after 200 first proposals I stop generating results. The proposals are sorted by relevance so I doubt it’s a big problem to get 200 of them. Thanks to this even the full list returned by PDT is assembled in fast manner, and the general performance of the PHP content assist in Orion is pretty satisfactory.

Another bug with content assist is a problem with a prefix passed to the proposals provider by Orion. The prefix is computed in such way that if you try to complete a dollar sign, “$“, which is common in PHP, the prefix variable is an empty string. This makes PDT return for example “$var” completion, which will be inserted into the editor and make “$$var” (because of the old dollar sign which wasn’t taken into account). Solving this problem is simple, and would probably require to define a list of special characters which will be treated as a part of a prefix. But the Orion devs need to take various languages into account, so I reported this bug.

Yet another bug with the content assist in Orion occurs when you switch to the content assist mode (i.e. invoke the proposals window by ctrl+space), and then start to press backspace to delete the chars before the caret. The proposals window is being updated, which is OK, but if you continue deleting and remove the preceding new line etc, the window is still open. I think it’s more common to automatically cancel the content assist mode in such situations, so I reported a bug.

Later I worked on some minor issues. I’ve added PHP heredoc highlighting rules for the syntax highlighter. Then I’ve checked how the new Linked Mode functionality I implemented lately works with Orion’s undo functionality, and surprisingly, it works without any problems :-).

In the meantime Mark took over my patch with Linked Mode feature and integrated it into Orion codebase! Of course he did some modifications and improvements. But this feature is now available both in the repos and latest integration builds. I wanted yet again sync my code with the current Orion, so I needed to update both my local installation and the oriondemo. I experienced some problems while doing this, despite the fact that I did it several times already. As it turned out, I forgot that John wrote on the list about recent repo address change. As Orion is the first-class Eclipse project now, the repo name is not e4 anymore but just orion. It took me way too much time to notice this, so updated a related Orion wiki page coincidentally.

For the next week I plan the bug hunting part 2. There’re a few more problems left I want to solve. When I’ll get through the problems on my side, I’d like to help Orion devs with some open bugs I reported. Hopefully I’ll produce some more patches :-).

content assist · gsoc · linked mode · oriondemo · pdt · summary · syntax highlighting