00:10 <luis> fiddlerwoaroof: so, I was thinking about how to use channels. slime-mrepl uses channels and it opens the channel by creating a channel then passing its ID to the Lisp side through slime-eval.

00:11 <luis> fiddlerwoaroof: and then I realized, slime-eval is basically RPC. And that's what most SLIME contribs use to communicate with SWANK.

00:12 <luis> fiddlerwoaroof: we don't need to set up custom SWANK events, we can simply use RPC. SLIME has this in the Elisp => Lisp direction, we just need to implement the same thing in the opposite direction.

00:12 <luis> fiddlerwoaroof: https://github.com/luismbo/slime/commit/446dd43e80da63d03444e8291ca25d38e1efdd41 what do you think about this?

00:14 <luis> And I think this removes the need for SWANK::*EVENT-HOOK*.

00:47 <luis> fiddlerwoaroof: regarding your responses to my pull request questions: ACK :-) I've updated those pr conversations

00:48 <fiddlerwoaroof> Hmm, *EVENT-HOOK* also has another use, I think

00:49 <fiddlerwoaroof> you can also handle an event, but return nil to let something else actually acknowledge the event

00:50 <fiddlerwoaroof> So, you could have an "inspect-communication" contrib that pipes all the events it sees to a buffer without actually handling them

00:50 <luis> Fair enough.

00:50 <fiddlerwoaroof> swank-rpc is a good idea, though, for other reasons

00:51 <fiddlerwoaroof> I have this in my init.el to allow me to use credentials in my CL code without actually sticking it in my source code: https://fwoar.co/pastebin/6cc633da2116a0428d6aa0bd74dbf39e3c77f55c.el.html

00:52 <luis> The main point of swank-rpc is that event handling is too low level, yeah.

00:52 <fiddlerwoaroof> a typical use case is something like this: https://fwoar.co/pastebin/12f520266abbfdb6fa16398e08be3e8bd6f12030.lisp.html

00:53 <fiddlerwoaroof> but e-i-e is a bit dangerous, and requires that the emacs user opt-in

00:53 <luis> Yep

00:54 <luis> I hope the read calls in swank-rpc are not too bad, security-wise

00:59 <luis> I'm off to bed. Unless you find something terribly wrong with this idea, I'll clean that commit up tomorrow and open a pull request.

01:00 <luis> I've abandoned the idea of splitting event dispatching in two, BTW. Not much benefit at this point.

01:01 <fiddlerwoaroof> Cool

01:02 <fiddlerwoaroof> We could bind *read-eval* to false, at least

01:02 <fiddlerwoaroof> But I'm not sure that Emacs -> Lisp security issues are particularly problematic

01:03 <fiddlerwoaroof> i.e. I don't think it's a horrible problem if the emacs user can execute arbitrary code in the inferior-lisp via READ, since they could also just type that code in the repl

01:03 <fiddlerwoaroof> anyways, goodnight

01:08 <luis> fiddlerwoaroof: This is the opposite direction, though: Lisp -> Emacs

01:08 <fiddlerwoaroof> Ah, misunderstood

01:08 <fiddlerwoaroof> Is the emacs reader fairly safe? I'm not really sure what it can do

01:09 <luis> Me neither. Something to investigate tomorrow. 👋

21:33 <luis> fiddlerwoaroof: I'm cleaning up yesterday's swank-rpc commit. Do you have any naming improvements to the event names (:swank-rpc, :swank-rpc-no-wait) and the function names (swank:emacs-rpc and swank:emacs-rpc-no-wait)?

21:35 <luis> :rpc-from-swank and :rpc-from-swank-no-wait are perhaps more informative event names

21:36 <luis> (It's nice to be able to tell which direction the event goes from the event name.)

21:49 <luis> Since people use SWANK with lesser editors like VIM, perhaps editor-rpc instead of emacs-rpc would be appropriate?

21:49 <luis> ed-rpc?

21:50 <luis> Naming is so hard. :-)

23:25 <luis> fiddlerwoaroof: https://github.com/slime/slime/pull/493 is ready for your reviewing pleasure