Event file missing chorded messages.
knusbaum opened this issue · 4 comments
It looks to me like the event file does not report chorded events as it does in acme, and as it says in acme(4).
acme(4)
:
[The event flag will contain bit] 8 if the command has an extra (chorded) argument; if so, two more complete messages will follow reporting the argument (with all numbers 0 except the character count) and where it originated, in the form of a fully-qualified button 3 style address.
In acme, selecting an Edit
replacement, e.g. ,s|foo|bar|g
and then chording the edit command Button3-1, results in the following events:
Event: [Mx19 23 9 4 Edit]
Event: [Mx0 0 0 12 ,s|foo|bar|g]
Event: [Mx0 0 0 0 ]
This matches the description in the manual page.
In Edwood however, the 8th bit of the flag is not set when chording, and no subsequent messages are received:
Event: [Mx21 25 1 4 Edit]
To be clear, chording appears to behave correctly in Edwood windows, but the events don't show up in the events file as expected.
I'll have a look.
Notes for trying to replicate this in Edwood (dd8fcfc):
9p read acme/105/event
...
Mx54 54 11 0
Mx53 57 0 4 Edit
Mx0 0 0 33 /Users/rjkroege/lib/tools:#47,#59
Mx0 0 0 12 ,x:^: i:> :
In Acme (e2a141ae0952c2d28a9f500bb9da6dc72e57be3c):
Mx55 55 11 0
Mx53 57 0 4 Edit
Mx0 0 0 11 x:^: i:// :
Mx0 0 0 0
Observations:
- Edwood does not include the
Mx0 0 0 0
- Edwood includes this
Mx0 0 0 33 /Users/rjkroege/lib/tools:#47,#59
stanza
exec.go:/func.*execute()
would seem responsible for the generation of event output. The block handling commands executed while the window's event
fid is open has no tests. 😛