- rewriting from scratch a whole Editor section from the first change to the last, even when everything inside is unchanged
I'm planning to work on that, but any help will be appreciated. See the cdt-dev thread entitled ASTRewrite question.
This clearly needs to be solved. I'm trying to find out if it's more viable to fix the issues I mentioned one-by-one, or just rewrite relevant parts of the ASTRewrite architecture from scratch. We have a nice array of tests already (and we have more cases reported in bug reports), so this might actually be not such a bad idea.
This is related to excessive rewrite. On top of that we need protection against modifying code produced by macro expansion.
Good point
- generating wrong formatting
Rewritten code has to be reformatted, but in order to do that we need to fix excessive rewriting first.
It's not just the matter of reformatting. Take the situation from
347501 where new code is inserted in wrong line. But I agree that this might be a side effect of some magic of excessive rewriting.
- requiring the file to be saved (unlike JDT, where you can do quick fixes and refactoring directly on a dirty working copy, without forcing save)
That's good to know! I'll have a look on that
- lack of reasonable ability to get file locations of newly created AST nodes (they are needed to create neat linked editor sections for user input after refactoring)
I don't understand the part in paretheses.
I'm referring to entering editor linked mode (org.eclipse.jface.text.link), which is the right thing to do in some refactorings (rename - see alt+r on a name in JDT) or after some quick fixes (for example when the user needs to fill some sections manually because the tool can't). To set up linked mode after a refactoring or a quick fix, you sometimes need document positions of the newly inserted nodes.
That's what I'd like to do in for instance Create Local Variable in cases when the tool can't infer the type - instead of just inserting `void`, the right choice is to set up linked mode there and let the user input it on his own, then return his cursor to where it was before. Editor already supports that, what's missing is new node positions after AST rewrite.
All refactorings except Rename are unusable at this point. The problems you outlined have to be solved to claim that CDT supports refactorings beyond simple rename.
I agree. Besides refactoring, it's also needed for Codan quick fixes and JDT-like quick assist (which I'd certainly like to see in CDT 9).
What do you think of my original point? Do you think it's profitable to attempt rewriting ASTRewrite, writing new solid code with that issues in mind, or is it better to keep patching what we already have problem-by-problem?
Best regards,
-- Tomasz
