Idea for enhanced editing scenarios: dynamic, nestable rows and columns for editing, analysis and visualisation.

[axefrog]

For a while now I've had an idea that I think would be really helpful when writing complex code and trying to mentally hold it all in my head. I don't know how difficult it would be to implement, but I'd be curious if the idea resonates with anyone.

Traditionally, code editing involves a text document with enhanced editing features such as line numbers, a margin for breakpoints, a drawable right column for things like "minimaps" and colored markers indicating lines with errors, and so forth. My question is this; can we take the editing experience a step further and break the document itself apart, for more streamlined editing, easier scanning and richer analysis?

The thought process behind this idea is that I often wish there were a way to move trailing code comments into a right-hand column. They'd then all be left-aligned in a uniform way, and would expand their corresponding lines of code in the main column vertically as much as is needed (sort of like how word wrap works). For big blocks of comments (i.e. `/* comments */) that start on a new line, I'd want to see those in a "left margin" column, and the vertical space they'd take up would kind of disassociate from the main document and be able to flow freely, with multiple lines of code to its right. It'd only push down subsequent lines of code when another block comment is extracted into the left column further down, as that comment would want to vertically-align with the code that follows it. All of this would happen dynamically, and the underlying document would actually be written to as though it were being edited directly.

Breaking it down:

My idea is to allow for additional columns that are "projections" of the primary document. By applying a set of patterns, aspects of the document can be displayed and edited in preceding or subsequent columns, all of which scroll together as a whole when scrolling the overall document. The main column may display the primary document as-is, or it may display a transformed version of the document, with the full set of columns providing an "enhanced" way to edit the underlying document. This could be used in many different ways, not only for enhanced editing, for dynamic, computed visualisations of aspects of the document, additional debug capabilities, and so forth. If designed in a generic fashion, extensions could make use of the functionality for a huge number of different purposes.

Here's how it would work:

1. Multiple columns (like with diff views) made available as a general-purpose API feature

A code editor (i.e. Monaco) would allow multiple editor columns where the lines in one editor correspond to the lines in the other. This functionality sort of already exists for the purposes of diff views, but could expanded for more general purpose usage. Scrolling up and down would affect each column equally, as it does with diff views.

2. Columns able to be broken into groups per block of code (think code folding, with columns per block)

In essence, think deeply-nestable rows and columns, down to individual lines of code, but with the columns in different rows able to be associated with each other, so that if a column in one row is expanded, the corresponding columns in other rows would expand to match.

A "row" would contain zero or more lines of code in the primary document, and would be analogous to a folded block of code as per the functionality in most modern code editors. The difference would be that rather than just being used as a way to hide and show a set of code lines, it could exist dynamically, both as a result of pattern matching against the primary document (a block comment might be an example of a pattern that starts a new row), or as a dynamic extension-driven feature for inserting visualisations and other features into the editor during coding.

3. The primary document being edited would not need to be displayed in the editor

Rather than displaying the document directly, typing into different rows and columns would apply changes under the hood back to the primary document. Think about the old days of HTML editors; the changes in the visible interface were written as HTML code under the hood. This idea would be like those WYSIWYG editors, but as a much more lightweight transformation of the document being edited. For example, if the additional columns are being used to extract trailing comments to separate, uniformly aligned comments columns (block comments moved to the left column and trailing comments moved to the right column), then typing comments into either of these columns would actually apply those comments as trailing comments in the underlying document. Beginning to type a trailing comment into the main column would automatically extract the comment text into the right column, and the double-forward-slash and trailing text would be hidden from the main column. The actual comment text would still be applied inline with the rest of the document under the hood as normal. You just wouldn't necessarily see it happening most of the time.

---

I don't have any immediate plans to implement this functionality myself, as my plate is pretty full, but I'm hoping to spark some interest in those that do work on this area of the code, or those who simply think this would dramatically enhance the potential capabilities of VS Code overall, both for developers, and for extension authors. At the very least, it'd be nice if it provides some additional ideas regarding the direction that the editing experience is headed.

[chrisdias]

Thanks for this suggestion. we are grooming our backlog this month and it is unlikely that we will address this feature in the next 6-12 months so closing.