• Path centered instead of 'project-file' centered (no files get in the way, configurations live in AppData)
• Class/enum browser
• Autocompletion (deep dot paths, []'s, scoping, immediate access of function return values, etc), member/function lists
• Function overloads helper/list
• Documentation on hover (assuming you wrote any)
• Multiple code-block snippets with "options" and "inputs"
• Events/Attributes lists with clipboard commands (copy subscriber, copy param getter, copy attribute getter/setter, etc)
• Find-in-files
• Verbatim console log of compiler output
• Error list (parsed from console output) with jump to file/line
• asPEEK debugging client, with watches/toggle-able-breakpoints/stack-traces/locals/this/etc (everything the web-client has)

• Implement a ScriptCompiler tool similar to Urho3D that can compile or dump C++ style headers
• Rip out the Events/Attributes/Script API tabs in the IDEView.xaml + all the latex parsing evil
• Assumes a single master file for compilation

The ScriptCompiler is not an option. The intellisense/autocomplete works by parsing C++ style header dumps from that are used to generate type information. That provides the class browser and is used for resolving auto-completion, there's some local file scanning used, but that's largely for finding the type something was declared as and for variable names.

Dependencies: ModernUI, AvalonEdit, Json.NET, WIXTools, Websocket4Net

Wow, two IDEs suddenly show up at the same time.

Options are always good. :D

Wow, two IDEs suddenly show up at the same time.

I noticed that, and it made me smile with an assurance that I'm not a nut.

I need to get around to installing QT to try the other one because I'm super curious about the performance differences of C#/WPF vs QT in this scenario. There's so much virtualization occurring in WPF that it can get irritating.

--------------

With the latest updates it should be much easier to use for a non-Urho3D project.

For practical reasons it still requires a Script API dump for your types that are registered to Angelscript, but compilers / info-tabs / editor-tabs have all been moved to a plugin system (that is trying to be simple enough to avoid the "time to go to MEF" scenario).

The dump is vital for getting information about the C/C++ types that are registered to Angelscript.

There are example plugins for CSV editing (datagrid), media viewing (image viewing / playback of audio available to windows media foundation), and XML editing without text with schema validation.

For compiling there's the UrhoCompilerPlugin which includes two compilers. One for single file compilation and another that compiles all files in the directory of the targeted file with adjusted log output to be readable for a many files compiled project. The main purpose of the mass compiler is for hunting down #include sequence issues and sample compilation.

"Intellisense" (well, it's basically 'string-ripping') has been abstracted out enough that it is viable to add support for most practical cases. HLSL/GLSL prototypes are included. HLSL is likely wrong, GLSL should be correct.

Experimentally there's also parsing of the active tab to generate a "Local Types" tree that contains a full #include processed tree of Angelscript variables, methods, namespaces, and types. This will likely fail with deep namespaces, imports, and funcdefs at the moment. Those issues won't be resolved for a few days. The "Local Types" are for the currently active file and based on the version that exists on disk, they will not refresh unless you save the file being edited.

"Go To Definition" is included with the "Local Type" processing. Super handy.