Chording the commands doesn't work

[paul-lalonde]

I'd like to keep my L* commands in a guide file and 2-1 chord to invoke them.
But using $winid to find the command context returns the window containing the command, not the target.
Instead, it should likely use the chordorigin parameter of the acme message.

[paul-lalonde]

I have an experiment now that reads the event file from the L command; this of course provides a poor experience because it reads the next event, not the previous event.
Next is to get acme-lsp itself to monitor the events on the source files and make them available to L.

[paul-lalonde]

A bit more poking around, and it's clear that getting the full event in L is ugly. This points to an alternate possible, though maybe less modular implementation.
@fhs Would it make sense to have the acme-lsp server itself keep an eye on each file's events and dispatch its recognized L commands directly? I could maintain some modularity by letting L accept an address parameter which if present becomes the file/address to pass instead of doing the dispatch to the lsp server directly from the acme watcher.
Have you given this any thought or do you have another design in mind?

[paul-lalonde]

Often I forget how much goodness is already in Acme.
$acmeaddr contains the chorded address, which L can easily interpret.
Patch incoming.