First videos of the structured editor prototype

Disclaimer: the structured editor work described in my posts is unrelated to my work at Microsoft. Everything shown is my personal research done as part of my MSc thesis during 2004-2007. Also, it’s not ready for real use and does not cover all the features of even C# 1.0. It’s a concept prototype and work in progress.

Introduction

As part of my research back in school I was building an experimental structured editor for C#. Now I’ve decided to publish the sources and binaries on CodePlex:

https://structurededitor.codeplex.com

A detailed discussion of structured editors deserves a separate post, which is coming soon. For now, to give a better idea of how the editor works, I’ve recorded six short videos showing the different features below. If your blog reader doesn’t support iframes, I recommend you view this post in the browser.

What is a structured editor?

Programs are represented as text by most code editors. Structured editors, on the contrary, directly display the syntax tree of a program on screen and allow the user to manipulate the tree directly (think MVC: program parse tree is a model, the editor displays a view of it):

This way the visual layout better illustrates the structure of the program and allows for atomic operations on the language constructs. A structured editor lets developers avoid syntax errors and concentrate on the meaning of the program instead of formatting.

1. Introduction

2. Editing

You will notice that there is no intellisense and coloring at the expression level – I did build a SharpDevelop add-in that hosts the structured editor control inside the SharpDevelop project system (DOM), but these videos were recorded on a stand-alone version of the structured editor control hosted inside an empty windows form. Also the support at the expression level is rudimentary, because so far I’ve concentrated the most at declaration level (namespaces, types, members) and statement level (except for single-line statements such as assignments).

 

3. Drag & Drop Support

4. No Parser Means Less Syntax

5. Properties

6. Modifiers

Background

Structured editing is a topic surrounded with scepticism and controversy for the past 20-30 years. Some argue that directly editing the AST on screen is inflexible and inconvenient, because the constraints of always having a correct program restrict the programmer way too much. Others expect structured editors to be more helpful than text editors because the user operates atomically and precisely on the language constructs, concentrating on the semantics and not on syntax.

In summer 2004, my professor Peter Bachmann initiated a student research project - we started building a structured editor for C#. I took part because I was deeply persuaded that good structured editors can actually be built, and it was challenging to go and find out for myself. After the original project was over, I took over the basic prototype and evolved it further to the state it is today.

As one of numerous confirmations for my thoughts, in 2004, Wesner Moise wrote:

...I see a revolution brewing within the next three years in the way source code is written.

Text editors are going to go away (for source code, that is)! Don't get me wrong, source code will still be in text files. However, future code editors will parse the code directly from the text file and will be display in a concise, graphical and nicely presented view with each element in the view representing a parse tree node. ...

I remember how I agreed with this! After three years, in 2007, the prototype implementation was ready - it became the result of my master's thesis. I still agree with what Wesner was envisioning in 2004 - with one exception. Now I believe that structured editors shouldn't (and can't) be a revolution - fully replacing text editors is a bad thing to do. Instead, structured editors should complement text editors to provide yet another view on the same source tree (internal representation, or AST).

My conclusions about structured editors

1. Text-based editors aren’t going away anytime soon.
2. Structured editors can only succeed by evolution, not revolution – hybrid approach and ability to toggle between text and structure is the way to go.
3. The main difficulty with structured editors is getting the usability right.
4. The right approach is solving all the numerous little problems one by one – find a solution for every situation where a text editor is better (from my experience, for any advantage of a text editor, a good structured solution can be found).
5. You need a graphical framework with auto-layout such as WPF to build a structured editor.
6. Don’t try to build a universal editor editor that can edit itself – this approach is too complex. Take a specific language and build a hardcoded editor for this language first. Only after you’ve built 2-3 successful editors, it makes sense to generalize and build a universal editor or an editor generator.
7. Compilers shouldn’t be a black box, but expose the data structures as a public API surface.
8. Syntax trees should be observable so that the editor can databind to them.
9. Traditional expression editor should be hostable inside a structured editor for single-line statements and expressions.

As a result of my work, I'm convinced that structured editors actually are, in some situations, more convenient than text editors and providing the programmer with two views on the code to choose from would be a benefit. Just like Visual Studio Class Designer - those who want to use it, well, just use it, and the rest continues to happily use the text editor. All these views should co-exist to provide the programmer with a richer palette of tools to chooce from.

Hence, my first important conclusion. A program's internal representation (the AST) should be observable to allow the MVC architecture - many views on the same internal code model. With MVC, all views will be automatically kept in sync with the model. This is where for example something like WPF data-binding would come in handy.

As for the structured editor itself - it is still a work in progress and I still hope to create a decent complement for text editors. It has to be usable and there are still a lot problems to solve before I can say: "Here, this editor is at least as good as the text editor". But I managed to solve so many challenging problems already, that I'm optimistic about the future.

Current implementation

The current implementation edits a substantial subset of C# 1.0 - namespaces, types, members (except events), and almost all statements. If you're interested, you can read more at https://www.guilabs.net and www.osenkov.com/diplom - those are two sites I built to tell the world about my efforts. I also accumulate my links about structured editing here: https://delicious.com/KirillOsenkov/StructuredEditors

More languages

It turned out that it makes sense to build structured editors not only for C#, but for other languages as well - XML, HTML, Epigram, Nemerle, etc. That is why, at the very beginning, the whole project was split in two parts - the editor framework and the C# editor built on top of it.

Links

1. https://structurededitor.codeplex.com
2. https://guilabs.net
3. https://www.osenkov.com/diplom
4. https://delicious.com/KirillOsenkov/StructuredEditors

If you want to know more, or if you want to share your opinion on this, please let me know. I welcome any feedback! Thanks!

Comments

• Anonymous
  September 17, 2009
  Brilliant! I would love to have this in Visual Studio with programattic read/write access as managed objects.

• Anonymous
  September 17, 2009
  The comment has been removed

• Anonymous
  September 18, 2009
  @Neal Blomfield You mean like, fxcop? haha.

• Anonymous
  September 18, 2009
  Yes, sort of. But realtime, as you type.

• Anonymous
  October 14, 2009
  I want it.

• Anonymous
  October 27, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  Hi Drew, thanks for the comment! usings are used to prevent naming collisions, just like in source code form. One COULD prompt the user for the full name, but a) this will interrupt workflow (never stand in the way of the user, never show modal dialogs, etc) b) what happens during a global rename that introduces naming conflicts? One COULD build a conflict prevention system with resolving conflicts, but this is a complex task and I didn't have resources for this. So what you're saying is correct, it's just I didn't have time for such things. Besides, usings are familiar to the user so I thought it's OK to keep them, at least for a while. Agreed, in a long term one can build a better solution than usings. Thanks! Kirill

• Anonymous
  November 26, 2009
  > directly display the syntax tree of a program on screen and allow the user to manipulate the tree directly Microsoft. Reinventing wheels since (whatever).

• Anonymous
  November 27, 2009
  Anonymous cowards. Missing the point since (whatever) :-P

• Anonymous
  November 29, 2009
  The comment has been removed

• Anonymous
  November 30, 2009
  Oleg - agreed. It's a huge user experience and usability challenge, I just enjoy solving such problems in my free time. I haven't seen a usable industrial-strength structured editor so far (except MS Word).

• Anonymous
  December 07, 2009
  Let me clarify my position: IMO it's evil :) for production/system development however it might be great for various kinds of RAD tools with zero entry fee. Btw Installaware has one but man it's terrible. SQLWindows's one looks nearly perfect.

• Anonymous
  December 08, 2009
  Thanks Oleg :) I got your point :)

• Anonymous
  August 08, 2010
  Kirill, I have to hand it to you -- your thesis and the structured editor you have built are brilliant. You also explain things very clearly, which is a bonus for people in the technical field who are not always great communicators. Now the idea of structured editing is not new as you have already noted, and many people have tried to build them without widespread success. I have been thinking about structured editors since about 1996 (though I did not know the term "structured editor" back then) and only recently have decided to see if anything was actually available for use in a real production environment.  I spent about 20-30 hours reading up on the topic, reading a variety of research papers, as well as checking out various actual implementations. This morning, I contributed some of this knowledge back into Wikipedia's Structured_editor article including links to some products and papers you may be interested in. After all this research, I've concluded that structured editing has failed to catch on for at least a couple reasons: Issue #1: Many of the structured editors that have been built lock you into a new IDE, or a new programming language, or a new file format. This kind of lock-in makes it difficult or impossible to interoperate with other existing tools/files/IDEs as well as increasing the amount of effort to learn how to use these things and not knowing if they will still be supported in a few years. Issue #2: Many desirable edits that are extremely easy to do in a text editor are hard to do in a structured editor, as you have already noted. When a developer edits a source code, he almost always starts off with code that is logical (parseable) and wants to end up with code that is logical (parseable), but may have to go through a few intermediate editing steps where the code is not logical (parseable).  Most structured Editors disallow those intermediate editing steps where the code would be illogical (not parseable), which is frustrating for most developers who are accustomed to being able to do these kinds of transformations easily and quickly. I think that issue #1 is somewhat easily overcome by making sure a structured editor works with an existing language using its native file format and existing IDEs. However, I'm not sure how easy it is to overcome Issue #2.  My feeling at this point is that for a structured editor to gain widespread acceptance, it has to allow "sloppy editing" similarly to what a text editor allows, for example allowing to convert string literals to method names to comments to etc. Then, the structured editor would do the best it can to allow logical (structured) viewing/editing where possible and flag any non-parseable code in some way to let the developer know that that area of code is not parseable. I'm eager to hear what your thoughts are on the above.  Are there any other major reasons that structured editors have not succeeded so far? Are you still pursuing your structured editor?  Is anyone using it in real production work (yourself included)? What is the proper name for your structured editor?  I saw the name "Libra" somewhere but I'm not sure if that's still the right name. Also, would you have any objections if I re-used some of your open-source code if I decided to go ahead and publish my own open-source structured editor (but it would be in Java and in Eclipse, since that's what I use at work) ? You know, the old saying of "standing on the shoulders of giants" ;-)

• Anonymous
  March 05, 2013
  Great! please ask microsoft to add the feature to VS2013.

• Anonymous
  June 09, 2016
  The comment has been removed