2014-10-29 11:41 GMT+01:00 Mark Rizun <mrizun@gmail.com>:

I had a look at the video, and it looks great. Certainly the way to go.
Well, it's not that great. And it shows pretty old version of what I have now. I should make a new better one:)
�
I had some ideas along those, but I never have time to try them. My interest would have been to show how many methods (and where: group-package-tag-class?) the search pattern will impact.
In current version you can generate rule(it creates class for your rule), and than you can select packages/classes/methods you want to apply this rule

This is the one which sounds difficult for me. Patterns are fairly global in nature, and they may match synonyms (i.e. methods of the same name but with different meanings), so I'm worried about the mastery of my changes.

For an isNil ifTrue: to ifNil:, it's easy. But for an indexAt: to at: because I'm changing an internal API, I'd like a better preview of what it will affect before launching it (or a way to examine the resulting changes, which is a bit convoluted).

�

�
One suggestion. When in the menu, try to auto-select the relevant keyword or literal;
You mean in all other panes? It would be really cool

You're jumping ahead of my mind :) Yes, it would be cool (but not sure it will be that easy to do in all cases; if you select @var1, would it highlight myVariable in the other panes... hum, interesting to have).

�

�
give access to the ast navigation stuff (up select the enclosing ast node, down the first node inside).
That's really great!� It'will take time, but I'm going to implement that, just have to remember:)

I think this is already available, you just have to use it (or trigger it).

�

I think you can work recreating the ast. I'm not sure there is any reason to keep track of old nodes, because what you do is: apply a change to ast under selection; rebuilt RB matching / transform rule; apply RB rule to sample code. update all four panes.

The process on video is: creating your own rule step by step. While doing this user may make a mistake.
I keep oldNodes, because I want to have an "Undo on node" action. It returns node into it's previous state.

In that case, I would keep the old node, and simply try to find where is the old node equal in the new ast when undoing (or when building the menu to show that an undo is possible on that node).

Thierry