How would you feel if your code editor formatted your code for you as you typed, without tabs/spaces?

Question

As with most things, I'm sure this concept has been tried before - I just haven't come across editors that use what I've termed 'Virtual Formatting'. The principle is that there's a floating left-margin that simulates the effect of the padding space/tab characters that are conventionally inserted by the developer or the editor itself to format the code. The editor continously parses code (even when commented-out) as you type and calculates the required indent based on the context where each line-feed is found

I'm developing this idea working specifically with an XML editor as XML has some peculiar problems with formatting characters and it tends to be heavily nested, however I believe many of the principles still hold for conventional code.

Have you experience coding with such a tool or do you have a view on whether it would help or hinder? Would it cause problems with version-control systems? (it detects and strips out all existing padding characters)

Unless you've tried it, the behavior of such a tool is hard to describe, it looks conventional until you actually start editing. I've put up a screencast video showing a prototype in action which demonstrates editing XML, changing it's hierarchy and doing drag/drop and copy and paste operations, and then how formatting is broken/fixed when invalid characters are typed.

Edit All answers/comments have so far been negative - so to attempt to redress balance, some benefits of virtual-formatting to think about:

• No more debates on formatting standards, just place line-feeds where that conforms to your chosen/mandated convention
• Where space is at a premium (in a book/blog/documentation) you can word-wrap but still getting perfect indentation
• Each code-block can have a 'mouse-handle' immediately adjacent to where it starts, not squeezed into the screen edge - click this to select the whole block or inner-block
• Drag, drop and forget - becomes viable for the first time
• No time spent reformatting other peoples code
• No incorrectly formatted code (in the sense that there is none - just the rendering)
• Using Backspace instead of Ctrl+Backspace keeps your fingers on the keyboard guide-keys
• Flexible rendering - adapt rendered formatting to your environment, anyone tried reading code on a mobile phone/small-screen tablet?
• Consider that there are roughly 25% fewer editable characters (in a sample XSLT), doesn't that have efficiency benefits?

Edit - Conclusions so far

1. Developers have established tools and working methods that efficiently overcome most of the disadvantages inherent in the use of padding characters used for indentation.

2. There is concern that removal of formatting characters will detrimentally affect some differencing tools.

3. Developers want the flexibility to 'fine-tune' formatting in such a way that automated rendering could not handle.

4. The removal of leading spaces/tabs means that a 'code-aware' tool capable of code-formatting is needed to review such code efficiently - a plain-text editor would show no formatting.

5. Those that feel there may be some hypothetical benefits (to virtual-indentation), have a view that the disadvantages outweigh those potential benefits - conclusively.

Edit - Verdict

The perception of the obstacles and few (if any) benefits is such that it would be unwise for me, as a sole-developer, to pursue this space-free editing concept for general languages. For XML/XSLT, however (because of its special treatment of whitespace), there seems to be some agreement of potential at least.

Edit - Product Shipped

In spite of the generally negative sentiment found here, I went ahead and shipped the editor. I made a free version in the hope it would bring criticism in the form of more concrete issues, based on real experience. Somewhat frustratingly, there have been no complaints so far (in fact barely any feedback considering download volume). I'd like to think this was because users adjusted to the idea so well that they see this as a 'so what?' kind of feature - but there's no way of telling...

Answer 1

The biggest problem would be how files would appear to other tools, most particularly version control tools. Line endings are significant to these tools. I would not want to see a merge screen where I have an entire class in one line and try and merge some part of the text at column 347.

Answer 2

That would be great. Emacs more or less does this, and mostly gets it right. Have you tried Emacs' nXML mode? How would you improve on that?

You can't build a new editor until you've sampled what's already available.

Anyway, the indentation has to be saved in the output file, so the file can be viewed with other tools. I'm not likely to adopt a new editor unless it supports run-time customization like Emacs.

Answer 3

I've seen this idea before, but I've never seen it actually work out. Most of the time, when I've seen the idea come up, it's been shot down by every developer out there - or when it has been implemented, it made version control virtually useless as merely viewing folded code would change the file and further confuse the diff tool. (An example of just how bad this is is the Witango Development Studio.)

I can think of several hurdles your editor would have to overcome in order to be useful to many developers:

• Changes to a file must not create noise in the *nix diff -uw command. (No spurious diffs!)
• Editing a (previously unformatted) file must not complicate merges in SCM tools.
• It must play nicely with other editors used by the dev team.
• Users must be able to customize formatting to their hearts' content - some people are quite passionate about how their code appears.
• Edits to existing code must not change the existing formatting. It's crucial that the editor doesn't suddenly reformat a whole file for no apparent reason and doesn't change the formatting of a line for simple minor edits - that'll confuse diff tools and anger other team members.
• It probably shouldn't strip excess whitespace - it'll probably piss someone off. Best not to risk it.
• New lines added to a file should conform to existing modelines' settings, or should conform to the local (within +/-3 lines) existing formatting.
• The editor should have a settings panel that allows the user to define the team's code formatting policy that is separate from what the editor actually shows.

Needless to say, it's obvious that this will require some amount of metadata about the file's existing formatting. You'd likely want to keep it separate from the sources, but keeping it in sync with an ever-changing repository would probably be quite difficult.

As a Vim user, I'd also opine that the editor should respect Vim, Emacs, and other editors' modelines and preserve the modeline's proscribed formatting, regardless of what it ultimately displays.

In my opinion, the requirements for such software make it untenable. Too many users will expect too much of it too often to make such a project successful.

Answer 4

Solution, using text-based (e.g., XML) formatter configuration files:

• Have a personal formatter configured by the individual developer.

  • Store this formatter locally.

  • Files are loaded and edited with local formatting.

  • They can freely change their formatting style without breaking anything.

  • Auto-formatting can be turned off to display and edit files raw.

• Have a minimal team formatter configured for the team standard.

  • Store this formatter in team version control.

  • Files are saved with team formatting as a fallback for other tools.

  • Diffs don't suffer from formatting problems.

It's ridiculous to worry about the economy of saving files without extraneous whitespace, so you don't actually lose anything by saving the files with some formatting defined by a team standard. In the case of a solo developer, you could offer the ability to have saved formatting (for the "team" of one) mirror displayed formatting.

When the formatter is insufficient, you have two viable options:

• Expose an interface for custom formatters.

  • Done right, this is the best solution.

  • Done wrong, it's the worst.

• Allow manual override of automatic formatting.

  • Usability doesn't suffer—consider Ctrl-(Enter|Tab|Space).

  • Sanity does—where do you save this formatting? Do you?

Answer 5

I'd be okay with code being autoformatted if the language wasn't format sensitive cough Python cough.

Emacs does Lisp formatting real nice, and it formatted on the fly I'd be pretty happy. I can't stand automatic insertion of parens or other delimiters: none of the autoinserters I've tried get it close to right for how I type.

Answer 6

I heart the idea in concept. And while you may succeed, I've yet to find an editor that sufficiently does everything I want it to do in terms of formatting. Here's a few roadblocks (IMO):

• Whitespace-picky languages
• What gets saved to output? (You would, to some degree, have to save at least some of the indenting so that it remains readable to others without the tool)
• It must absolutely play nice with the existing source/versioning control products already in place
• It must be highly customizable, especially for those of us (me included) that are very, very, very picky about how code gets formatted and indented (and where that comma should go in a list, but if the list is really long, how lines should be broken, etc.)
• It must truly understand the language. By this I mean that it must follow the language exactly as the compiler will understand it. I've had far too many editors with colored syntax that get the syntax wrong because there is some nutty facet of the language that can't simply be handled with a RegExp. Granted, you indicated that you would be continually parsing the language, but who is to say that what you parse conforms to the compiler I'm using? (Believe me, there's a lot of standards out there, and there's a lot of funny-business that goes on in most languages, including code that looks wrong to a simple parser, but is perfectly correct to the compiler.)
• It must be fast. And here's where the rubber meets the road -- you can't be doing a full compile run on my code every keystroke (especially with a large project), unless you can optimize your parser to the Nth degree. If there's even a hint of slowness in the editor, no one will use it. (I'm a perfect example of abandoning slow editors in favor of faster ones. If it lags in the least, I'm out.)

Could you create something that meets most of the criteria reasonably well? Probably. But we programmers are finicky and picky and loathe to change and will jump-ship at the first sign of trouble. Here you're trouble is going to be if the output ticks someone else off on the dev team, or if it doesn't play 100% nice with the versioning system, or if it doesn't format my code exactly so or if it misunderstands the language and mis-indents my code, or if it lags a millisecond beyond what I expect. Because, much as I heart the idea, I'll jump ship to my preferred editors in a heartbeat.

Answer 7

There exist an even more radical approach - a pure semantic editor. An IDE deals with a code which is even represented internally as an AST, not a plain text. See JetBrains MPS for example.

Answer 8

Now that I've published the XML editor described in my question, I'm in a better (but not ideal) position to attempt to answer this myself - so I will:

After well over 500 downloads in less than 2 weeks, the reaction to this ground-breaking new concept in dynamic code formatting has been...

NIL

No complaints, no praise. My (hopeful) interpretation of this is that people just want and expect an editor that feels normal and doesn't mess up their code. Users will barely notice that their formatting is entirely virtual and evidence suggests they care even less.

It would be a mistake though to read too much into this non-reaction, this tool is free, and unfortunately this means at least some users will be less inclined to criticise. If they didn't like it, they may just have discarded it and used something else.