Dynamic propagation of events in `SET-EVENT` -- dependant on handler?

[simendsjo]

SET-EVENT has :CANCEL-EVENT to avoid propagating the event, when non-nil, the event is not propagated. The problem is that I would like it to be dependenant on the result of my HANDLER.

My exact use-case is that I would like to be able to use nkeymaps to get emacs-like keymaps, and for a keypress I'd like to look it up in my keymaps and propagating only if no keybinding exists.

Any idea how I might implement this?

[rabbibotton]

I did a bit of work on this last year, but found small workarounds. I will make this a priority to look at this next week. Took the last month and half off for happy occasions (3 new grandsons). Probably start on in Sunday or Monday

[rabbibotton]

I may have solution for you soon. Sorry for delays

[simendsjo]

Guess you forgot about this? :) If you point me in the right direction, I can take a stab at it myself.

[rabbibotton]

Haven't forgotten just I have not been able to free up project time yet. Very soon.

[simendsjo]

If you have a fix in mind, you can give me a hint in the right direction, and I'll look into creating a PR.

[rabbibotton]

My area was under 6ft water (ft lauderdale) right after holidays, been dealing with water damage, etc, soon sorry

[rabbibotton]

Sorry for the delay... like a year delay. To many IRL issues to apply myself to this until now.

The means to accomplish this is to use :post-eval in set-event to setup and use a java script promise (or other way to block till return value received) to sync up the results of Lisp handler and the return of the java script event that called the handler. Not sure that makes sense to you, but once I get a working example I will show you.

The biggest concerns are delays. This should not be an issue on a local machine but the network latency will be the time one waits from hitting one key and seeing the result, so a server in Europe and a client in the US would really feel the lag.

Once I have the example working we can test and see. Perhaps less of a concern than I might think.

[rabbibotton]

I am still working on a general method for this but in the mean time a simple solution is an event like this.

(source p) and (result p) or two form inputs:

(set-on-key-down (source p)
  (lambda (obj data)
    (declare (ignore obj))
    (setf (text-value (result p)) (format nil "key - ~a" (getf data :key)))
    (setf (text-value (source p)) (getf data :key)))
  :disable-default t)))

I do realize this is not exactly the same in that now you would have to handle all the functionality not just filter a keystroke.

JS is not truly multi-tasking so there is no semaphores that we could use to block the return until we receive a second message from our lisp code with the result to use.

[rabbibotton]

It doesn't seem that waiting for events mid JavaScript handlers a bad idea. I plan on working on using ECL client side with WSAM. In the mean time you would have to write the handler to filter the event and dynamically choose the return value using ParanScript or JavaScript. There is an example of how to use ParanScript with CLOG in the discussions.