Figure 7 – approaching the ideal editor from different sides
Probably the biggest predicted problem of a structured editor implementation is the usability problem. While editing text is straightforward and consistent (only some basic operations are needed, such as insert a character, delete a character, move the caret, etc), editing the AST structure on the screen requires learning how to operate on each node of the program. Moreover, editors that force the user to use menu, toolbars or the mouse during editing are most probably destined to fail. Text editors allow to edit programs using keyboard only and users won’t give up this ability.
That is why, a structured editor must be more usable than a text editor by at least the amount necessary to convince users to transition to structured editing. This puts tremendous constraints on the user interface, the biggest of them being able to use keyboard only. Also, the comparative amount of key press operations to achieve same functionality must be lower than amount required in text editors. Another restriction is that the editor must be consistent (different language constructs must be operated the same way). Only under these strict circumstances the end-user will even consider giving the structured editor a chance.
Even if structured editors could be better than text editors in all areas, there would still be an important advantage of text editors over structured editors: users throughout the world are well familiar to text editors. For example, if you have ever used Notepad, you will be immediately familiar with the editors of [SlickEdit], Visual Studio ([VS]), [ReSharper], [Eclipse], [IntelliJ] IDEA, etc. Structured editors must offer sufficient value over text editors while preserving all their advantages, and this is a very complicated problem.
While text editors become more intelligent and usable by applying more and more constraints to what can be typed in plain text, structured editors move to the same goal from the opposite direction: they start with the strictest constraints that arise from the hierarchical nature of the program and relax some constraints to allow temporary incorrect program states for improved and simplified editing experience.
Figure 7 – approaching the ideal editor from different sides
As noted in section 1.3.2, text editors aren’t limited by the semantics of the language and allow the program to be in an incorrect state, for example, if it is required to provide more flexible editing experience. Structured editors either lack this freedom to corrupt the program for the sake of usability, or must weaken (or sacrifice) the constraints posed by correctness checks to provide the user with the necessary flexibility. This is a compromise every developer of a structured editor must face sooner or later.
The editor shouldn’t stand in the way. The user shouln’t notice the editor just like people don’t notice the pen they’re writing with.
Somewhere in between there is the editor of the future, with just the right amount of flexibility and language-awareness.
Software developers and development teams choose to develop a product using a specific programming language or a combination of languages. This brings in a language dependency, but still leaves the freedom to choose the IDE for that language. If the source code is stored as plain text, it is easy to open it in a different IDE without the need to convert anything.
But if the developer/team chooses a specific structured IDE, the dependency is much greater. Not only the source code will probably be stored in a custom format of this IDE, the developers might get used to the concrete editor and it would be difficult to change the IDE in the future. However, the problem is solvable. An IDE might (and most probably will) provide an option to store source code in text files, just like traditional IDEs do. Or the storage format could be standartized, just like a programming language syntax is standartized. Beside standardizing programming languages of the future, it will probably make sense to simultaneously standartize the structured storage/representation format for programs in that language.
Many developers would feel very uncomfortable if the custom formatting of their source code would be influenced or even completely lost by an editor. Imagine a situation where existing source code is stored in text files with custom whitespace formatting and comments. Such formatting (as indentation or empty lines) could carry important information for the developer, or even convey vital information via the team’s coding conventions.
The problem is that a structured editor is typically unaware of whitespace and formatting because formatting is not formalized by the language grammar and is ignored at the scanning phase.
However, this problem could be solved by using a formatting preserving parser, which not only stores text position (line and column) information for every node of the AST, but also stores special nodes that represent all the textual whitespace between the language constructs, which is normally being ignored by traditional scanners.
This formatting information should be taken into account by the structured editor and the pretty-printer should output the source code including all the whitespace.
An interesting research direction could be automatically deducing whitespace formatting rules from the existing source code and auto-inserting such whitespace when new nodes are created in the structured editor. For example, the editor should notice that there is always an empty line between methods of a class, so it should automatically guess and insert an empty line around a newly created method. However this task is obviously very complicated because of its non-deterministic nature and also because whitespace formatting is something that is being mostly ignored by the compiler and programming language research.
It is already difficult enough to come up with a standard for a programming language, including its grammar and semantics.
Most often standards do not cover code representation (formatting and coding guidelines), because this is not formalized as good as the language syntax.
Coming up with standards for a structured editor for a language is a highly challenging and vastly non-trivial task. Such a standard would need not only to cover the appearance of all language constructs in all possible contexts, including margins, padding, colors, border thickness, styles of backgrounds etc. but it would also have to describe and formally specify the editing behavior, keystrokes, visual changes in display and so on. Such a specification would probably be more voluminous than the HTML 4.0 specification, because HTML only covers static presentation and does not include complex runtime behaviors exhibited by structured editors.
Previous: 1.4. Principles of structured editors