Stuff accepted in code pane is swallowed without confirmation

[LinqLover]

Steps to reproduce

1. Record some message sends and open a record browser on them
2. Select a method from the stack list
3. Make some code changes to the code pane
4. Accept it

Expected behavior

One of the following options should apply:

1. The code pane is read-only
2. When accepting the code, the method is recompiled but after that, the old code is loaded again (preferred option)
3. When accepting the code, a message tells you that this is not possible
4. Accepting the code is impossible and the orange triangle will stay after hitting <cmd>s.

Actual behavior

The code is replaced with the original method source, and the changes are lost.

[marceltaeumel]

I would prefer option (3) or (4) because users should remain able write into the code pane. Why would you want to edit/compile/change actual source code in the system through that tool (option (2))?

[LinqLover]

I'm not sure, but we support this in the debugger, too (at least I believe I proposed something like this to the inbox some time ago). The MSR tries to behave and look like a debugger in many scenarios, doesn't it? I'm thinking of a situation where I am using an MSR to find some bug and as soon as I found it in some method, I'm fixing it immediately before closing the MSR again. In this scenario, it would save me some seconds if I didn't need to copy-paste my changes into a regular browser to accept them there.

[marceltaeumel]

At least in the debugger, you can change a method to then influcence the onward stepping behavior. Is there such a use case for MSR? You can actually develop a system through debugging because the use is looking at present information. MSR shows you a past run.

[LinqLover]

I'm often thinking of the MSR as a "timeless debugging tool", so I would inspect the records of a complex operation in order to find a bug. Such a bug could also include situations where I realize "ah, this cannot work, I have to pass an additional parameter here"! So to fix the bug, I would add the parameter to a method and fix its sender, and if I am using an MSR at this moment, it would be most easy for me to use it for adding that method.

However, this is only a rare use case from my point of view, so option 3 or 4 would also not be that bad ... :-)

[marceltaeumel]

I'm often thinking of the MSR as a "timeless debugging tool"

That's dangerous. That assumption might lead to a misunderstanding of references-vs-copies of arguments etc. Well, maybe you find a way to spawn an actual debugger at a certain point. From there you could modify the source code.