luis changed the topic of #slime to: SLIME, the Superior Lisp Interaction Mode for Emacs | | |
<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.
<luis> fiddlerwoaroof: and then I realized, slime-eval is basically RPC. And that's what most SLIME contribs use to communicate with SWANK.
<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.
<luis> And I think this removes the need for SWANK::*EVENT-HOOK*.
<luis> fiddlerwoaroof: regarding your responses to my pull request questions: ACK :-) I've updated those pr conversations
<fiddlerwoaroof> Hmm, *EVENT-HOOK* also has another use, I think
<fiddlerwoaroof> you can also handle an event, but return nil to let something else actually acknowledge the event
<fiddlerwoaroof> So, you could have an "inspect-communication" contrib that pipes all the events it sees to a buffer without actually handling them
<luis> Fair enough.
<fiddlerwoaroof> swank-rpc is a good idea, though, for other reasons
<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:
<luis> The main point of swank-rpc is that event handling is too low level, yeah.
<fiddlerwoaroof> a typical use case is something like this:
<fiddlerwoaroof> but e-i-e is a bit dangerous, and requires that the emacs user opt-in
<luis> Yep
<luis> I hope the read calls in swank-rpc are not too bad, security-wise
<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.
<luis> I've abandoned the idea of splitting event dispatching in two, BTW. Not much benefit at this point.
<fiddlerwoaroof> Cool
<fiddlerwoaroof> We could bind *read-eval* to false, at least
<fiddlerwoaroof> But I'm not sure that Emacs -> Lisp security issues are particularly problematic
<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
<fiddlerwoaroof> anyways, goodnight
<luis> fiddlerwoaroof: This is the opposite direction, though: Lisp -> Emacs
<fiddlerwoaroof> Ah, misunderstood
<fiddlerwoaroof> Is the emacs reader fairly safe? I'm not really sure what it can do
<luis> Me neither. Something to investigate tomorrow. 👋
prite has joined #slime
makomo has joined #slime
scymtym has quit [Ping timeout: 245 seconds]
scymtym has joined #slime
scymtym_ has joined #slime
scymtym has quit [Ping timeout: 240 seconds]
scymtym_ has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
scymtym has joined #slime
cage_ has joined #slime
scymtym has quit [Ping timeout: 250 seconds]
prite has quit [Ping timeout: 246 seconds]
cage_ has quit [Remote host closed the connection]
cage_ has joined #slime
prite has joined #slime
cage_ has quit [Remote host closed the connection]
scymtym has joined #slime
prite has quit [Ping timeout: 250 seconds]
<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)?
<luis> :rpc-from-swank and :rpc-from-swank-no-wait are perhaps more informative event names
<luis> (It's nice to be able to tell which direction the event goes from the event name.)
<luis> Since people use SWANK with lesser editors like VIM, perhaps editor-rpc instead of emacs-rpc would be appropriate?
<luis> ed-rpc?
<luis> Naming is so hard. :-)
<luis> fiddlerwoaroof: is ready for your reviewing pleasure