After using method browser to create a new method with a new selector, cannot revert to original method in that browser

[dalehenrich]

Here's a case where I browsed the method GsGenerator371Common>>generateGemStoneBootstrap:gsDestDir:doCompile: and then extended the selector to include doCheckTonelClassMethodOrder:doCheckTonelClassMethodOrder: ... Note that method listed in selection list no longer matches the method in the code page:

I cannot deselect/select the original method selector and get back to the original method source ... I'm pretty sure this worked in earlier versions of JfP ... just not sure when it stopped working ...

[dalehenrich]

... and the plot thickens, if I navigate to the original method in the projectBrowser and edit it to call the new selector, I get a you have unsaved changes notification and cannot save the method with the old selector:

It seems that the project browser shares the incorrect notion of "which selector am I editting"

[dalehenrich]

If I click yes I lose the changes in the method I am trying to save ...

[dalehenrich]

commit ids:

JadeiteForPharo 2f873ab
PharoGemStoneFFI 78f7581
RemoteServiceReplication 9a3398d
---------------------------------------------
RowanClientServices cfe8285

[LisaAlmarode]

Testing in the current does not show the serious problem Dale saw 4 weeks ago. Perhaps it healed meanwhile.

The only issue I see is the complaint about the method list and method pane not matching. After the save, the method pane shows the new method, which does not match the method name in the search results. If you unselect using control select and then select, the old method contents is shown (correctly), and you have to go to the PB to find your new method; but editing the old to call the new worked fine too.

The mismatch is not ideal, but the alternatives are not great. When you edit the method to add a keyword you can just as well create a brand new unrelated method, so while this case seems like both should be visible since they look similar, the devil's in the details.

We could:
-- unselect the previously selected method, so there is no mismatch, but keep showing the new method. This is weird but less weird than the mismatch (I think...)
-- continue to show the contents of the originally selected method (new method disappears), as in GBS.
-- rerun the search (automatically or manually) so it can pick up the new method in a case like this, in which the new method would have met the search criteria.
-- Change this instance of method browser to become an ad-hoc list of methods that combines the search results that created this list, with methods added since that window was opened. you'd want to fix the title.

The bad part of this bug was a P2, but the remaining part is a P4, so I've made this a P3. Dale should retest the bad part of this bug, and Eric can look at what we might want to do (if anything) about the mismatch.