> > 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). >
You will see upcoming changes in Changes browser, so you can decide if it's what you really want. It's like applying refactoring. I think this is already available, you just have to use it (or trigger it). > I'm not aware of this kind of things, can you specify where it is available? 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). > That's pretty much the same what I'm doing. Mark
