&gt; It can allow you to edit code faster, make changes faster, refactor faster, because rather than editing at the &quot;text-level&quot; abstraction, you&#x27;re editing at the &quot;code-level&quot; abstraction.<p>I explicitly stated that I at least don&#x27;t <i>perceive</i> editing (keystroke) speed as a limiting factor, so I&#x27;m not sure what you&#x27;re trying to say. My perceptions may obviously be wrong, but I think this places the burden of proof on those claiming an improvement.<p>My point (or contention, if you will) is that the power gained through local refactoring like this (moving a bunch of parenthesized code around quickly) is absolutely negligable in the grand scheme of things.<p>&gt; By itself it&#x27;s not that useful, but combine it with type awareness, semantic awareness, you have an expert system, not just a code editor.<p>That&#x27;s really the crux isn&#x27;t it? I can only say that I haven&#x27;t seen anything even close to <i>this</i> yet even from AST-only editors, and we&#x27;ve been promised it for <i>sooooo</i> many years.<p>As of now IntelliJ IDEA&#x2F;Eclipse can do <i>far</i> more advanced refactorings at the press of a few buttons... and some of these refactorings are <i>actually</i> non-trivial -- as opposed to just doing a block-select and moving code.<p>Granted, I&#x27;m sure they have a <i>lot</i> of code to achieve that, but I&#x27;d wager that the actual <i>parsing</i> from text-&gt;AST is a <i>very</i> minor portion of the refactoring code. I&#x27;m pretty sure the most difficult bit of that refactoring code is the bit that guarantees that the refactor <i>preserves semantics</i>.<p>EDIT: What I&#x27;m saying is basically this: I think it&#x27;s naïve to think that the AST is the big problem when doing IDE&#x2F;editor-supported refactoring.