So my project’s goal was to develop a plugin with the most important PHP editor features for Orion. To summarize in one sentence what is Orion I’d say that it’s the Eclipse Platform for the web. Of course this is still an exaggeration as Orion is a very young Eclipse project. But even on this early stage Orion has a better online source code editor than any other web IDE over there, in my opinion. And my plugin adds a support for editing PHP files into this editor.

Together with my mentor Jacek, yet back in the proposal stage we defined as list of features PHP editor should have and prioritized them. Then we decided that it’ll better to actually pick up few big features and work on the than to fragment my time for many small and not so important ones. And so we’ve chosen three of them: syntax highlighting, code validation, and content assist.

After implementing these features I think it was the right choice – the PHP editor actually seems to be pretty usable already. Of course many things are lacking, and some bugs were detected on Orion side. Many of them were fixed my Mark, and for some I even prepared patches which are now integrated with the trunk ;-). I described the problems that still exist in the blog posts linked above.

GSoC 2011 was a great learning experience for me. I got to know a lot about the Eclipse Foundation, and the whole ecosystem, how the open source code is being developed, what tools are used, etc. I of course got to know many things about the Orion itself. I’d like to recommend any student to participate in Google Summer of Code, especially under the wings of the Eclipse Foundation :-).

I’d like to thank my mentor Jacek Pospychala for being very helpful when all the GSoC coding took off and even before it. Also I’m very thankful for Orion developers for the help I received many times on orion-dev mailing list as well as on the Bugzilla (big thanks to Mark who was promptly responding to my ramblings on it and who actually turned my patches to an usable form ;-)).

Thank you!

Syntax Highlighting

TextMate grammars

Orion uses a grammar-file based syntax highlighting. The TextMate’s syntax highlighting system is the role model for Orion’s implementation. Not the whole TextMate’s grammar file’s syntax is supported, but the most important parts are. The grammars are defined as .js files in Orion, as opposed to .plist files in TextMate, and are much more readable in general. The grammar rules are used to select some parts of the text buffer, to which a CSS style is attached afterwards. They are applied in a hierarchical manner, so for example is the style name is .keyword-control-exception-php, all of the .keyword-control-exception, .keyword-control, .keyword will be also applied. This is great as you can both define a detailed language-specific styles and reuse the preexisting, general ones too. You can read more about the TextMate grammars on it’s manual and blog, as most of the specification applies to Orion. If you want to see the existing grammar files, take a look at their github repo.

Your own grammar rules in Orion

To add syntax highlighting to your own language of choice, you need to create a grammar file. It looks like this one. Name it [lang]Grammar.js (for example phpGrammar.js). The rules themselves can be almost directly copied from corresponding TextMate file. Just keep in mind the differences between Oniguruma and JavaScript’s regex engine, escape the special symbols etc.

Another important file is your plugin.html file, which looks like this one. You need to register you grammar file. In my example the registration part is commented out, as in order to get the multi-mode syntax highlighting (PHP in HTML) I needed to modify HtmlGrammar to actually hande .php files. More about later.

This is how simple grammar rules converted from TextMate look like in phpGrammar.js:

Bugs and multi-mode highlighting

You can read about the bugs related to syntax highlighting that are still open, on the blog post I linked in entry paragraph. I provided a patch for one important feature which is now in trunk thanks to Mark, namely multi-mode syntax highlighting. It’s about a possibility to highlight PHP mixed with HTML, JS within HTML and so on. In TextMate, to highlight one language within another, a concept of external references is used. For example, HTML grammar defines a rule for catching the PHP open / close tags, for which it then includes PHP grammar. It’s a problematic solution as HTML grammar has to “know” about all the languages it wants to include, so it’s not very plugin-friendly. This is why I had to modify HTML grammar to test this feature. But this is how it works in TextMate.

Look at my modified htmlGrammar.js file to see how to use external references.

Content Assist

How it works in Orion

Orion has a concept of content assist proposals providers. You have to register your own proposal which has to follow pretty straightforward API. Take a look at phpContentAssist.js file. Please note that this provider retrieves it’s proposals from the server side, where a PDT installation resides.

The real work is done on the server side, in PhpServlet. Most of the work is initializing and configuring PDT, but if you look into getProposalInfo() method you may notice a specific structure which is being returned (it’s later converted to JSON). It’s for the Linked Mode feature that I provided a patch for some time ago. If the proposal is a method, and has parameters, their’s offsets and lengths are provided and Orion will set up the Linked Mode – pressing tab will switch between these parameters in a cyclic manner.

Please note that Orion supports many content assist providers for one file. So as long as your provider can handle multiple-languages soup, it’s not a problem at all to create for example PHP content assistance for PHP embedded code snippets, and HTML content assistance for the rest of the code, in one file.

Code Validation

Code Validation has similar architecture as Content Assist in Orion. You have to register your provider, and you can register many providers for one file type. The extension point is called orion.edit.validator. The phpValidator.js file is very simple as the real validation is done at the server, using PDT. You can find the corresponding code in PhpServlet I linked above.

The code for registering a problem provider is very simple and looks like this:

Other

During the whole coding period I was regularly updating my test Orion installation. You can see and test the plugin features by yourself, live, for free. Check out this post for details. :-)

So, this is relatively brief summary of the plugin’s internals and features, but I think it’s a good start for anyone who wants to develop a custom plugin or maybe build upon this one, etc. You can find much more details in the status report posts I was writing every week. Feel free to browse this blog and ask questions if something is not clear. Thanks!

Bugs

First things first, these are some bugs I experienced. They can be on your way too especially if you want to develop a plugin to add support for a new language. Please note that most of these problems will probably be fixed in not so far future by Orion devs. These are the ones that still exists:

• Begin/End patterns are buggy in TextMateStyler (#345191) – this is a very important bug in syntax highlighting in Orion. If you use begin/end patterns in your grammar file (which is a very commonly used feature), the styler might colorize the code incorrectly on change. So, when you just load the editor, the syntax is highlighted correctly. But when you start adding and removing lines, the repairer is getting confused a little bit. Currently refreshing the page helps.
• You cannot attach your own CSS style to the editor (#347493) – as you may read in the bug comments on bugzilla, Orion supports multiple CSS styles but you cannot attach them yet from plugin’s perspective. So, to add your own syntax-highlighting style, you have to edit default-theme.css file directly.
• Content assist proposal can be placed in a wrong place if you move the caret (#350494) – If you invoke CA, then move your caret (using mouse), and then choose the proposal, it’ll be placed in the new caret’s position. Instead the proposal window should disappear. This problem will be fixed when TextView will provide mouse-click event.
• TextMateStyler doesn’t support a case insensitive flag (#348347) – the (?i) flag is very commonly used in TextMate grammar rules. Currently TextMateStyler doesn’t support that yet.
• Completion prefix is computed incorrectly in some cases (#352756) – If your language uses some kind of special character, like PHP uses a dollar sign for variables, Orion may compute a completion prefix incorrectly. As a result, instead of inserting $var for example, it’ll insert $$var.
• Content assist feature may behave unfamiliar on Backspace key (#352782) – When you have your completion window opened, and you tap a Backspace key, the proposals will be shown even if you move to the line above etc. The completion window should be canceled at some point.

Various problems

Below are problems that are not strict bugs, but provided me a headache many times during development of my plugin. Please note that these are from perspective of a JavaScript as well as Eclipse newbie. If something is illogical here, please let me know :).

• Plugin not loading, blank screen, etc – Sometimes when I changed something in the code and wanted to test it out, I was experiencing problems with loading the changes or Orion itself. It can be a black screen, plugin not listed in the plugins list (so not loaded), or “old” behavior even if the plugin seems to be listed. My advices are as follows. Double check all the edited files. Make sure they are in correct place and that you’re not doing something stupid ;). Invoke localStorage.clear() in your browser’s JS console. Many times, just in case ;P. If the problem persists, use all the clear-cache options your browser have (also just in case). Test if the problem occurs in another browser. Hit hard refresh many times.
• Orion is not fully loading (grey sidebar and empty editor visible) – This is what I experience actually every single time when I invoke localStorage.clear(). Just hit the hard refresh button (e.g. CTRL+F5) many times. Like 10 times. It’ll eventually catch on. Note that if you’ve changed just one file, and you know the webroot location for it, you may just open it in your browser and refresh so it’s redownloaded. Then just refresh the Orion window – no need to clear the local storage. However, the plugin files you include in your plugin.html file won’t refresh that way.
• Orion server doesn’t work correctly even if all dependencies are satisfied – if you’re experimenting with your own server-side bundles, and want to run it using Eclipse Platform as described on Orion wiki, you may need to change the run configuration to not use features but individual bundles (to include yours). If it’s the case, don’t trust the “Select required bundles” option of Eclipse. It won’t select dojox bundle for example. Check the list and select the ones that were in Orion target platform but are not selected. Also if you’re hacking on Orion bundles, make sure that you run it against the most recent target platform! If everything fails, don’t forget about the debug trace feature of Eclipse plugins (.options file), turn it on.

Your problem may me known on bugzilla. Check there first. If nothing helps, ask on orion-dev mailing list. They will know the answer, just be patient.

PS: if you want to browse the Orion source code online, these are valid links for client and server. Make sure you’re not browsing or pulling from the old repositories, from e4.

Good luck! :-)

Just make sure that you know how to install Orion on your own machine, how to use OSGi console and Eclipse plugins. My goal was to create as simple instructions as possible, but some problems can get complicated anyway. Also make sure that you’re using the correct version of Orion (too new is also bad as Orion is still evolving rapidly, so the plugin might be not compatible).

After some tests I got back to the modified files to add some comments and make the code clean. I also looked into the CSS file modifications and other modifications related to the particular syntax highlighting plugin, PHP syntax highlight. These parts of the code are not required for using the multi-mode syntax highlighting feature, but I wanted to prepare a separate patch for that so anyone interested can see how to utilize this new feature.

Then after my mentor’s advice I’ve took a look into a content assist feature. Can it cooperate with the new mutli-mode syntax highlighting? How will it know what part of the code is relevant? Well, thanks to Orion design it’s very easy to attach multiple content assist providers to one file format. As the phpContentAssist is already attached to .php files by my plugin, it started to work right away. That was a nice surprise! :) It’s because the PDT has totally no problem with handling PHP-HTML mix. It just doesn’t suggest any proposals for non-php code.

I was experiencing some problems with opening PHP files in the Orion editor after applying the modifications. The browser wanted to download the file instead of showing it on the website. This happens when the editor is not configured to handle this particular file format. But I did configure it to open .php files, and the problem still persisted. As later came out, the problem was probably in the browser cache mechanism (I’m still not sure the localStorage.clear() didn’t work that time, but after cleaning some other cache options in the browser it started to work).

After solving this problem out, I updated my oriondemo installation. You can test the latest changes there by yourself. I also prepared two patches – one with the language agnostic multi-mode syntax highlighting feature, and another one with php-specific modifications. The latter one was not meant to be applied to Orion trunk of course, it was more like a reference for anyone to use.

This is the screenshot of multi-mode syntax highlighting. Oh, and the code validation feature works too:

The nice thing about doing patches is that eventually someone will use them ;). Mark applied my last two patches, one for better content assist panel, and one for the multi-mode syntax highlighting I’ve just written about. Of course he modified them, added test cases etc, but I’m glad it came in useful :).

As you might have notice, this blog report is a little bit late (I used to post them on Sundays). It’s because I just moved to Sweden and I had to do (and still have) a lot of stuff to organize my life here and prepare for studies. As the Google Summer of Code 2011 is slowly coming to it’s end, for the following days I plan to write a documentation for all the modifications and new features I’ve made, a detailed installation instructions and so on. I also want to reorganize the code and make the git repo look more logical. And of course I’d like to document some problems and obstacles I experienced while implementing a plugin for Orion, so it can be easier for other people ;).

Firstly I edited the ide.css file to add overflow: scroll property and a fixed height (150px). It was enough to make the panel display horizontal and vertical scrollbar. But a new problem occurred – the scroll position was not related to the currently selected item at all – using arrow keys to move up / down haven’t scrolled the panel, so the selection went easily out of sight.

I modified then contentAssist.js file to implement the scrolling. I used the node.scrollIntoView() method do the scrolling on every selection change. This method accepts a boolean parameter – when true, the panel will be scrolled as much as it’s needed to display the selected element at the top of the window, while providing false will show the element at the bottom. It’s the typical behavior you would expect in such situation.

To prevent the panel of being displayed out of the viewport, I added two conditional statements in panel’s initialization code. First, it checks if the bottom line of the panel is not outside of the viewport – if it is, the panel will be displayed above the caret, and not below it as usual. Second, the same thing is done for right edge of the viewport and panel. But this time, if the panel doesn’t fit, it’ll be displayed just next to the right edge (“snapped” to it). This is the behavior I observed in desktop Eclipse Platform and I think it’s the most common.

This simple changes allowed the panel to behave in a way that is much more convenient and useful. You can test the changes by yourself! Just go to this file on oriondemo, place the caret near the bottom and / or right edge of the editor and invoke the content assist by ctrl+space. This is how it’s displayed near the bottom / right edge of the viewport:

I prepared a patch and added it to the issue on bugzilla. I didn’t test the changes on many browsers (just FF4 and Chrome) but I hope it’ll be useful for the devs.

Multi-mode syntax highlighting

After the patch was ready I proceeded to the next, more important task – implementation of multi-mode syntax highlighting. Currently, only one language grammar is used for highlighting any file. So, if it’s an HTML file, only HTML syntax will be highlighted. And if it’s a PHP file, the syntax will be highlighted even outside of start and end tags. It is a major lack so I really want to change this ;).

I started with looking into HTML.plist, PHP.plist TextMate grammar files to get some insight how this problem is solved there. As it turned out, there is no concept of grammar inheritance as I firstly thought, but just the external reference is being used. For example, the HTML.plist file is defined as a grammar for *.html files, but also *.php, *.js, and few others. Then in the grammar body, some rules exist to “catch” the begin / end tags for particular languages, and in pattern list for body of this capture, external grammar is included. Grammars have names (for php its “source.php“), so just this name is given.

Such solution has a drawback – the “main” grammar file has to know about all the included languages. This is a problem from the perspective of pluginability, but nevertheless I wanted to try implementing support for external references in Orion’s textMateStyler.js (as it currently doesn’t support these of course) and check how it would work.

I’ve looked into the textMateStyler.js and setup.js which is instantiating the former to check how to add this feature. I came to conclusion, that in theory it should be enough to provide a list of all known grammar objects to textMateStyler.js (aside of providing just one grammar as it’s now), modify the preprocess() method to accept any grammar object and not just the “main” one (it converts the grammar rules into a more useful, preprocessed form), and, the most important part, reimplement _resolve() method to not throw an exception when an external reference is detected. Instead, it’s needed to go through the array of all known grammars and compare it’s name. If it matches, it should be enough to invoke the preprocess() method with the just recognized grammar as a parameter.

The theory didn’t worked as nice in practice, as usual, but all the problems were simple ones caused by my absence of mind ;). After fixing these, surprisingly, the highlighting of PHP inside of HTML just started to work!

I’m very happy that it worked just like that, but of course it’s just a proof of concept. It’s very inefficient, no cache, no handling of corner cases etc, so I didn’t place it on oriondemo yet.

Next week I’ll further work on this feature to make it nice and efficient. There’s a lot stuff to do here, but I think it’s a very important feature – probably the most important I’ll do a patch for :D

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 :-).

So this time I wanted to prepare yet another quick-and-dirty demo to check if the code validation feature of PDT can be used from outside of the Eclipse Platform context. It didn’t work at first, so I’ve enabled the tracing data and started to debug the code, to check what exactly is failing (I was just receiving an empty array instead of an array of problem markers). I noticed that the markers are generated correctly in one point, but then they are removed from the array. It turned out that the array is being filtered by a problem’s type, which is passed as a parameter to findMarkers() method. In PDT unit tests a constant DefaultProblem.MARKER_TYPE_PROBLEM is being passed, so I did the same ;-). But after changing this parameter to just null, my markers finally started to show up. According to the source code’s comment of findMarkers() method, passing null makes the method to just return markers of all types. I’m not sure why it’s like that in PDT’s unit tests.

After ensuring that I can retrieve the problem’s list for any particular PHP script, I started to modify PhpServlet to handle the new functionality. From now on it had to support requests in two formats, /php/contentassist/ for the “old” feature, and /php/codevalidation/ for the brand new stuff. The new mode expects a script parameter, and optionally phpversion. It returns a simple JSON array, with elements of following structure:


{
reason: "A problem description",
line: 3,
character: 1
}


This is just a structure that orion.edit.validator expects (more about it in a moment). Line is just a number of line where the problem occurs, and character is a number of column in this line. However this particular value is not being used by Orion yet.

On the client side, I had to just connect to the mentioned orion.edit.validator extension point to make Orion display the problem markers. The extension points are now very nicely described on wiki, so it’s easier now to do everything as it should be.

However, while implementing the client code I’ve encountered a very weird problem. After initial versions of files phpValidator.js (provides markers’ array to the mentioned extension point) and phpEditingPlugin.html (registers the object from former file) were ready, I cleared the localStorage as I always do and prepared to test the new feature. But then all the contents of files in my workspace disappeared, and any attempt to save any text just failed. The files were staying empty. I noticed that while invoking the save action (by a keyboard shortcut or by using a navigation button) an error was showing up in the console: “TypeError: result is null“. So I’ve looked into the code where the error occurs, and it seemed like the servers’ response is invalid. But the file operations functionality which was failing has nothing to do with the parts I’ve changed! Moreover, I reverted my modifications, cleared everything I can in the browser, and even removed server-side Orion workspace files. It didn’t help, my local installation was just broken. I tried to debug the client-side and server-side code but I didn’t get any clues what’s wrong.

After wasting too much time on this already I came up with an idea to just test my modifications on the remote installation (oriondemo) to see if the problem will also come out here. I did exactly same steps as before, and this time it just worked! Code validation is working as expected and you can test it by yourself :-). Just remember that you might need to issue localStorage.clear() if you’ve visited the demo recently (and it may require many subsequent F5 keystrokes ;-)). At present I still don’t know what is the problem with my local installation and why it occurred. I’ll try to investigate this issue but as my code works, I committed it to my github repo.

When you hover a mouse pointer over the marker you will see the error message (reason).

The next week will be a bug-fixing week for me. I plan to concentrate on some problems I postponed or ignored before. There are many various problems that need to be fixed, as the code still has very prototype-like nature in general. :-)

I started with implementing the Linked Mode activated on key shortcut. The positions were hardcoded, so only the same part of the text were being selected over and over again. Then I added a key actions for TAB – to traverse through the positions (in cyclic manner) – and for ESC to exit the Linked Mode. After exiting the “old” bindings are reattached (i.e. inserting tab on TAB key :)). Also the position “groups” (selections) are being updated if the user inputs a text (or deletes) within the group. If it’s done outside the group, the Linked Mode is canceled.

As the simple version was working I started to create an API so the content assist feature could later use the Linked Mode while completing methods with parameters. After that I had to modify contentAssist.js of course, so it could prepare data needed to activate the mode (i.e. offsets and lengths of the position groups, as well as the escape position – a place where the caret has to be inserted after the Linked Mode is exited). Finally my phpContentAssist plugin and the responding server-side code had to be modified to provide that data (the contentAssist.js is language-agnostic so it cannot know what is a parameter and what not in a completion proposal).

After some more tinkering all started to work nicely. Almost all actually, as I experienced some problems not related to the new feature itself. First, the Linked Mode won’t be turned on if you choose the proposal from the list by mouse click (as opposed to enter key). These two events are handled in two different places in code, so I didn’t want to duplicate my handling routine just yet to not unnecessarily mess up the prototype. The second problem is that the selection object doesn’t seem to be updated before calling onModelChanged, so I needed to do little hack to get the up-to-date caret position every time. And the third problem occurs when you invoke the completion proposals’ window, then click somewhere else (place caret on another line), and then click enter to select the proposal – it’ll be inserted in the wrong place. But it’s a known issue reported by Mark – the textView.js has to expose a new event first to fix this.

Finally after cleaning out the code I’ve updated git repo (also new README) and the tracker issue and added the diff patch of the new feature. When updating my Orion demo installation I experienced one more problem. It turned out that the Orion target package includes a built-edit.js instead of edit.js file by default. The former one is a “precompiled” version of few files included by edit.js (so e.g. my modifications of editorFeatures.js weren’t picked up). But I changed the relevant line of code and now you can test the new Linked Mode by yourself in oriondemo. Just please don’t save the modifications of prepared files :).

The task for next week is the code validation feature for PHP, which I omitted earlier to proceed with content assist. But as this time I can return to and I’m curious about the effects :).

Then I started to look into Orion code and get a little bit familiar with it. I’ve searched for the parts related to storing and using information about current selection (so also the caret position) in the editor. I got to know that the textView.js is mostly responsible for that, and that it also exposes some methods to read and change the caret position or selection. But there are also files like editorFeatures.js or commands.js which use this information (for incremental find and so on).

But the hardest problem was to actually learn how the desktop Eclipse is achieving its functionality of “controlled caret movement” when traversing through the arguments’ list for a method being autocompleted. I had no idea where can I start looking for, and googling didn’t really yield any useful results. It was mainly because I really didn’t know the official name for this functionality. But then I somehow stumbled upon this article, where the name Linked Mode occurs. It was a good anchor for me, and then finding the package responsible for Linked Mode, which is org.eclipse.jface.text.link, was easier. Then I checked the org.eclipse.dltk.ui plugin, as I thought it must be using the Linked Mode to its content assist feature, and I found AbstractScriptCompletionProposal class, among other where LinkedModeUI was used.

It was a very helpful finding as I could finally see how it is exactly implemented in Eclipse. But one thing wondered me – why the completion proposals I was receiving from PDT on my server, didn’t contain method’s parameters, even though they were defined in the code. Always a method name with just opening and closing bracket was returned (and it still is – you can test it in my Orion installation). I’m still not sure why it is like that as the method I’m using for retrieving the proposals – getCompletion() seems to be invoking findParameterNames() to get the parameters and place them in the returned completion. Nevertheless I’ve done a quick test of invoking this method by myself and I got nice array of parameters, so this is really not an issue.

And finally today I’ve updated the bug about the Linked Mode, adding some API details of this feature. The biggest problem is how to implement the Linked Mode itself. The other tasks, like modifying contentAssist.js to actually support the aided completion of parameters using the Linked Mode, and updating my plugin to utilize this feature are much easier to do. However the Linked Mode itself seems to be very core-related part, requiring to modify the textView.js file which is a heart of the Orion editor. Anyway, I plan to give it a try and experiment with this feature next week. I hope to implement some simple prototype that will actually work :). If I’ll experience some big problems, I’ll just proceed to the next part of my proposal – code validation – and maybe get back to this feature later.