Consulo: ~ 1000 commits, or how autumn went

For those who missed my posts:

Consulo is a fork of IntelliJ IDEA Community Edition, which has .NET support (C # at the moment, and there is a lot of emphasis on this sector), Java, Javascript (NodeJS) and much more. The project has collected many open plugins in itself. At the same time, the code remained open.

Despite the fact that many of my friends are already using it with might and main in production development of Unity3D for Mac OS, I still can not boast of a stable release.

Below I will tell you how my autumn went, and how these three months of constant work influenced the .NET + C # plugins, and much more.

New resolving

I will start, perhaps, with the most voluminous task of those that stood before me - I needed to completely rewrite the syntax search (namespace, classes, methods, fields in .cs files, etc.).

Pull Request


Before rewriting the algorithm, working with small modules went smoothly, but if the program grew to 10 or more classes, then the responsiveness of the IDE became a big problem. I even had to introduce the ability to optionally turn off the search, because otherwise users with a weak PC configuration, Consulo constantly crashed.

This was a difficult step, because I needed to rethink the existing search algorithm and rewrite it taking into account all the weaknesses. The first iterations cannot be called successful, but in the end I managed to bring the new algorithm to my mind and successfully contain this pull request.

I want to express special thanks to Denis Shevchenko from pragmatix-corp.com, who helped me in testing the plugin.

Generic & Lambdas

My headache. After implementing a new search, I took up the lambdas that are used, for example, in LINQ . However, to implement lambdas and LINQ, I needed to solve the problems with finding the Generic Type . In the process, I implemented basic inference for the generic parameters - and lambdas worked somewhere in 50% of cases. At the moment, the task on lambdas ( issue 157 ) has not been completed , the implementation of which, as expected, will solve all the remaining problems.

Code Style

From the very beginning of work on the C # plugin, I did not pay any attention to this issue, because I got used to the “hardcore”, which displays the code as follows:



At the request of several people, I paid attention to this and added the initial settings of the C # code style, and now By default, the code looks like this in the IDE:

LINQ

I put this task aside to the farthest corner, because I once decided that this was not a priority task. That was so until yesterday. It was like this:



Somehow not really, right?

And I thought so. And I decided to still pay attention to this, and after one day of coding, everything looks much better.

And what else?

I haven’t described a lot of things, this is the introduction of Covariance + Contravariance support, the method search rewriting, the type system redesign, a bunch of edits to many subsystems of the .NET + C # plugins.

I also did not write about how I tried to fix task 140 , as a result I broke everything, I had to roll back and transfer everything to PR 149 .

What's next?

And then with us - the most interesting.

Nuget

The ability to download and automatically add NuGet libraries was added via packages.config. So far, they have been downloaded only from nuget.org and there is no visual viewing of libraries, but this will fix some of the problems when they are used from the repository.

Unity3d

Yes Unity3D. I finally decided to look this way. What was done

• Separate Module Extension, forget that Mono .NET
• Unity bundle support separate from Mono .NET SDK, lose no direct paths
• (inital support) Support for compiling a Unity project
• (inital support) Support for debugging Unity games, while only local ones (android & ios while waiting), at the same time you need to use the build with Unity Editor. It is not yet clear how to throw the Debug flag through command line project compilation. Unfortunately - the debug is very far from ideal, there are many stability problems, it does not start from the first run. But a start has been made.
  
  

Java as .NET app (IKVM.NET)

I also look in this direction, trying to bring to mind the implementation. A static and dynamic compilation of Java code now works. In this case, a partial search. But that is where the good news ends. There are stability problems, the IKVM.NET plugin can easily put Consulo on the shoulder blades (or user: D). The plans are to make .NET debugger support in Java code (we are waiting for the latest Mono build for Windows).

The end?

Only the end of the article. I will continue to do what I did. The plans - to bring to mind what is already there.

Although I do everything myself, I have many “holes” in places where my hands simply do not want to.

If anyone wants to help me with the site, with writing plugins (Java language, but I also need people who know C # to write Microsoft Debugger), or with testing - write me in the dialogs on Habr, or on the mail

Thank you.

PS:

C # is not the end, but only the beginning