Hi tim,


> you absolutely do *not* reselect the original text selection after a printit because we want the printed output selected. This is to allow quick deletion (since it is already selected) or copy etc.

I think I see what you mean, but did you try loading the commit? :) #printIt calls #evaluateSelectionAndDo:, and in the specified do block, it prints out the result and adjusts the selection to the output. So this will keep working fine. Or am I misunderstanding you?

Further, you are suggesting that we should only change the selection if the user cancels the compilation on a warning. (By the way, this selection is made in Parser >> #queryUndefined, for example. You can find out this quite easy by debugging the invocation of the dialog window and peeling back the stack.)
Personally, I would disagree with that change of behavior. Perhaps it may depend on your image's setting regarding focus & modal exclusivity, but I find it quite helpful to see the place where the error occurred selected while watching the message:

[cid:e196680d-d2a1-434e-9978-be19ce648c1c]

So my point is that the selection should be changed whenever a parser notification is raised.
Ergo, the selection might change at some point during parsing/compiling. If the user cancels the operation, this selection should stay so the user can fix the code directly. Otherwise, the warning is skipped and the temporary selection is no longer relevant to the user, so we should restore the previous selection.

What am I missing? :-)

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von tim Rowledge <tim at rowledge.org>
Gesendet: Sonntag, 8. Dezember 2019 20:12:15
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1606.mcz

Christoph - you absolutely do *not* reselect the original text selection after a printit because we want the printed output selected. This is to allow quick deletion (since it is already selected) or copy etc.

There *is* a but shown up by the example you gave
>> | x |
>> x.
>> 2
where the compiler complaint about an unassigned var seems to mess up the selection but that is quite different. It looks like the selection gets messed up by the error handling. Somewhere code is setting the selection to be the apparently problematic variable name, which may well be sensible in some scenarios. However, if the result of the notification is to proceed the selection ought not have changed and the printIt result will be put in the right place.

It seems proper to change the selection if the user says to not proceed; that way the problem will be selected and I think that is plausibly helpful. If the user say to proceed then the selection should not be changed. The trick now is to find the place where it gets changed, and I have to admit that a quick scan for usages of OutOfScopeNotification didn't enlighten me much. Somewhere in the bowels of the compiler there will be a place.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: BBL: Branch on Burned out Light



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191208/9f26435e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 14658 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191208/9f26435e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 15575 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191208/9f26435e/attachment-0001.png>