MessageBrowser labelling improved

Am 24.11.2019 02:48:28 schrieb tim Rowledge <[hidden email]>:

Something that has irritated me for ages has finally driven me to bang on it and make things a smidge less annoying.

When you open a message browser (with an 'implementors of' for example) it normally starts up with a perfectly reasonable looking label; like 'Senders of add:rn:imm:ror: (4)' in my image today. Click on one of the listed methods and the label gets changed to the less helpful 'senders of add:'. Sigh.

What happens is that the message name passed to the tool building gets 'processed' and a multi-argument keyword gets truncated to the first part of the message - hence #add:rn:imm:ror: -> #add:. This seems to have been done to allow the auto-select to try to find the first instance of the relevant message in the code. However, several layers of changes over the years appear to have combined to make things a bit more complex than necessary and a couple of simple changes can make the window label more consistent.

Instead of keeping an array of pre-processed message names we can keep the entire thing. When the method is selected and the text view updated it can be passed a processed message name. That way the window label that is derived from the message can stay 'correct'. There is still one weirdness that I can't be fussed with today, where the window label when nothing is selected become e.g. 'Senders of add:rn:imm:ror: (4)'. I can see that having the number of instances attached might be interesting but it becomes a bit pointless as soon as you use the message tracing to add in some senders or implementors - now there are more than the original number!

We could - should - improve the way the message is found and selected in the text view. Right now it is a trivial string search for the first case of the shortened selector. We do better than this in the debugger, so maybe someone might like to try using the same tricks to highlight the first case of the full message, which would have the nice extra bonus of not 'finding' in the comments.

The attached changeset seems to do the job but I've been wrong before and might have missed something.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DNPG: Do Not Pass Go