2014-10-29 15:54 GMT+01:00 Mark Rizun <mri...@gmail.com>: > 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. >
You mean the changes tool in Monticello ? > It's like applying refactoring. > Hum. Yes. > > > > 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. > Oh well, then you're done ;) Thierry > > Mark >
