rjkroege/edwood

Event file missing chorded messages.

knusbaum opened this issue · 4 comments

knusbaum commented

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.

paul-lalonde commented
rjkroege commented

I'll have a look.

  • 👍1
rjkroege commented

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
rjkroege commented

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. 😛