I think that is what I mean, yes. Bangs are currently exempt from the “things in locked ports don’t act” rule, it seems sensible and less surprising to not have that exemption — but I don’t know all possible repercussions of that.
That’s why I was trying to understand the mechanics of banging and port locking.
How to catch that… BTW, my T*
example above was misplaced, it does behave correctly and I was confusing that with the memory of https://github.com/hundredrabbits/Orca/issues/235, which is also an interesting example.
Consider couple of examples:
...............
..C............
..58T*.....**..
.....:01Da.....
This one is a little contrived, but :
is getting banged by T
s operand *
in a locking input port. Minor, but surprising nonetheless.
...............
.........C.....
..x*.....02t*..
..*........*...
...............
These lowercase operators keep operating because they’re banged by a nearby *
in what would have been their locked input port if they were active.
The logic to catch both of these cases could be: if a bang is in a locked input port of an active operator OR a bang is about to activate an operator such that it will be in its locked input port, then no bang. I understand lowercase operators don’t become active until they’re banged, so implementation may not be very straightforward. It would allow them to operate on bangs the same way active ones do, I think that would be consistent and pretty useful.
Thanks!