After 5 months of intense work MonoDevelop 0.13 has been released. It includes lots of new features and fixes. Thanks to all contributors that made it possible!

This is not yet the first beta release we planned for this month (well, in fact for last month), because there are several features that still need to be finished and polished. I hope we can finish all them for the next release. I'm optimistic because in addition to Ankit Jain, we now have Jeffrey Stedfast working full time on MonoDevelop (welcome!).

Making a release is stressing. I always have the feeling that after publishing the packages, a last minute fix will break everything. I should take some real resting this weekend. Although I have the feeling that I wont. Hmm.

Enjoy!

I'm probably one of the most constant MonoDevelop users, and although my opinion as user may be a bit biased, I really feel that I'm very productive using the IDE, specially after the latest features implemented and the bugs that have been fixed. I'm going to summarize some of them, and since I've been hacking quite a lot on code completion lately I'll start writing about that.

Code Completion Performance

There were several long time pending bug reports, and I also wanted to improve a bit the performance and memory use. MonoDevelop creates a Parser Information Database (pidb) file for each assembly or project. This file contains all the information about classes implemented in an assembly, together with documentation pulled from Monodoc. A pidb file has trhee sections: the first one is a header which contains among other things the version of the file format (that version is checked when loading the pidb, and the file will be regenerated if it doesn't match the current implementation version). The second section is the index of the pidb file. It contains an index of all classes in the database. The index is always fully loaded in memory to be able to quickly locate classes. The third section of the file contains all the class information: list of methods, fields, properties, documentation for each of those, and so on. Each entry in the index has a file offset field, which can be used to completely load all the information of a class (the index only contains the name).

So, one of the changes that I've done lately is to replicate some of the class data in the index. Not to much data (only the class type, modifier flags and some other flags), but enough to be able to fill a code completion window without having to read any other class information from the database. This results in a big improvement in performance, and also some improvement in memory (although the parser service already did a good job in managing class information memory).

Showing subclasses

A nice improvement is a better support of completion of the "is" and "as" keywords, and the implementation of completion for "new" (which still won't be able to complete in all cases, for example in method parameters). Properly implementing completion of those keywords requires getting all direct and indirect subclasses of a given class. So if you type: "CollectionBase b; b as ", it will show all subclasses of CollectionBase. The same for "b = new ...", and when the type is an interface, it should show all classes implementing that interface, and all subclasses of that class. To be able to quickly get this information I had to add base-class/subclasses relation information in the pidb index (since recursively scanning all the databases would be really slow). So now the index is a bit bigger, but getting a complete subclass tree is very fast (fast enough to be useful).


Did you see that? The type of the variable is selected by default in the list. That's cool :-).

Improved Code Completion Infrastructure

Another important improvement I've done is removing all c# language specific checks from the generic code completion classes. Some of the checks done to determine if the code completion window had to be shown and the entries it had to offer were specific to c# (for example, checks for "using" or "is/as"). This was an important limitation for other language bindings, and for c# itself, since there wasn't a chance to support code completion in more complex contexts.

To solve this problem, there is now a TextEditorExtension class which can be implemented by any language binding to support code completion. In this class a language binding has full control of the whole code completion process, and can provide completion for situations not previously supported by the generic classes. For example, this morning I implemented support for completing overridable members. That is, when you type "override" on a class declaration, a code completion window will be shown offering a list of members which are virtual/abstract in base classes (it will show interface members too). When selecting a name, MD will create the full declaration of the member. Here is a visual example:Ah, this example also shows another improvement in code completion: full support for instantiated generic types. So, if you have a variable of type List, the code completion window will show all methods using the int parameter type.

Improvements in Version Control

I'm also saving a lot of time thanks to this window:



This is what you get when you run the Status/Commit command on a folder: a list of all files which have changes. You can expand a file to see the changes, mark it for commit and enter a commit message. You can even select multiple files and enter a comment for all them at the same time. What is also interesting is that comments are stored in disk, so if you close MonoDevelop and restart it again, the status window will show the comments you entered.

So, when I've done several changes in several MD projects, I run a "Status/Commit" command on the root MD solution, and see what changed. I can browse through the changes and enter comments for them. I can select files from all projects and enter the same comment if I need to. I then I run the status command on a specific project (for example the CSharpBinding project) and I click on the Commit command. This is what you get:



The commit dialog will summarize all commit messages from all files, and will group files which have the same message, and will update the ChangeLog file if there is one in that directory. I haven't manually edited a ChangeLog file for several weeks now, and I certainly don't miss it.

Version control integration in the solution pad

We've had source control integration in the solution pad since the first version of the addin. There is a Version control menu which looks like this:



However, nowadays version control integration is much better. When a project is under version control, all file operations you can do in the solution pad, such as copying. moving and deleting files, will be handled by the version control system. So for example, if in the project shown in the previous screenshot I move the file Main.cs to the Tercera folder (by just dragging it there), this is what I would get:



The version control system takes care of the move operation, that's way it is registered and the "Status/Commit" command shows the resuling remove + add operation. The same would happen when deleting or renaming a file or folder.

MonoDevelop is slowly getting in shape for the 1.0 release. There are still many bugs to be fixed (although I squashed quite a lot in the last two weeks), and we are a bit delayed according to the plan posted some months ago, but we are on track.