[slime-devel] Add hook to swank::dispatch-event
What do you think about adding a hook to swank::dispatch-event, much alike the mechanism in slime-dispatch-event? The purpose would be to support any set of commands that the contribs add, or even the user, through .swank.lisp or any other means. Right now, you can't send any command to Emacs that isn't in dispatch-event's destructuring-case. Paulo Madeira
Hi guys, Do you know how to enable fuzzy completion bind on <tab> key on both slime and REPL buffer? It seems REPL need be enabled separately. <tab> would be the most intuitive key but naively setting it below would cause conflict with normal tab functionality, i.e. indentation. (define-key slime-mode-map (kbd "<tab>") 'slime-fuzzy-complete-symbol) I would be nice to enable the completion only at the end of the word. Thanks for your help in advance. -chris
"Chris Kim" <chrisk414@hotmail.com> writes:
Hi guys,
Do you know how to enable fuzzy completion bind on <tab> key on both slime and REPL buffer? It seems REPL need be enabled separately.
<tab> would be the most intuitive key but naively setting it below would cause conflict with normal tab functionality, i.e. indentation. (define-key slime-mode-map (kbd "<tab>") 'slime-fuzzy-complete-symbol) I would be nice to enable the completion only at the end of the word. Try slime-indent-and-complete-symbol instead.
-- With best regards, Stas.
Great!! You gave me an idea and found slime-fuzzy-indent-and-complete-symbol which is exactly what I want. Thanks a lot! -chris -----원본 메시지----- From: Stas Boukarev Sent: Friday, April 15, 2011 8:08 AM To: Chris Kim Cc: slime-devel@common-lisp.net Subject: Re: [slime-devel] Fuzzy Completion on "Chris Kim" <chrisk414@hotmail.com> writes:
Hi guys,
Do you know how to enable fuzzy completion bind on <tab> key on both slime and REPL buffer? It seems REPL need be enabled separately.
<tab> would be the most intuitive key but naively setting it below would cause conflict with normal tab functionality, i.e. indentation. (define-key slime-mode-map (kbd "<tab>") 'slime-fuzzy-complete-symbol) I would be nice to enable the completion only at the end of the word. Try slime-indent-and-complete-symbol instead.
-- With best regards, Stas.
Great!!
You gave me an idea and found slime-fuzzy-indent-and-complete-symbol which is exactly what I want. Thanks a lot! That wasn't the idea, the idea was to use slime-indent-and-complete-symbol. It will use fuzzy completion if it's
"Chris Kim" <chrisk414@hotmail.com> writes: the default completion. `slime-simple-complete-symbol' variable is used to determine the default completion method. You can either customize it, or set directly to `slime-fuzzy-complete-symbol' -- With best regards, Stas.
Great!!
You gave me an idea and found slime-fuzzy-indent-and-complete-symbol which is exactly what I want. Thanks a lot! That wasn't the idea, the idea was to use slime-indent-and-complete-symbol. It will use fuzzy completion if it's
Got it! Thanks. -chris -----원본 메시지----- From: Stas Boukarev Sent: Saturday, April 16, 2011 2:49 AM To: Chris Kim Cc: slime-devel@common-lisp.net Subject: Re: [slime-devel] Fuzzy Completion on "Chris Kim" <chrisk414@hotmail.com> writes: the default completion. `slime-simple-complete-symbol' variable is used to determine the default completion method. You can either customize it, or set directly to `slime-fuzzy-complete-symbol' -- With best regards, Stas.
2011/4/14 Paulo Madeira <acelent@gmail.com>:
What do you think about adding a hook to swank::dispatch-event, much alike the mechanism in slime-dispatch-event? The purpose would be to support any set of commands that the contribs add, or even the user, through .swank.lisp or any other means.
Right now, you can't send any command to Emacs that isn't in dispatch-event's destructuring-case.
I've attached a patch implementing this suggestion, please take a look at it. I don't know if add-hook should be exported too and if a remove-hook should be implemented. I suggest that we eventually refactor all the contrib's events that are in swank::dispatch-event out into their respective source files, e.g. making functions that return non-nil when they handle an event and add-hook them in the end of the file. Regards, Paulo Madeira
* Paulo Madeira [2011-04-14 20:52] writes:
What do you think about adding a hook to swank::dispatch-event, much alike the mechanism in slime-dispatch-event? The purpose would be to support any set of commands that the contribs add, or even the user, through .swank.lisp or any other means.
Right now, you can't send any command to Emacs that isn't in dispatch-event's destructuring-case.
What kind of commands do you need? Contribs can add new functions with defslimefun and Emacs can call those without much pain. Slime also has "channels" (see contrib/slime-mrepl.el for an example) which, at least in theory, allow you to run custom protocols that don't match the RPC paradigm. Helmut
2011/5/22 Helmut Eller:
What kind of commands do you need? Contribs can add new functions with defslimefun and Emacs can call those without much pain. Slime also has "channels" (see contrib/slime-mrepl.el for an example) which, at least in theory, allow you to run custom protocols that don't match the RPC paradigm.
I'd like to add normal RPC commands that the Lisp implementation could tell the client to handle. Right now, the only allowed commands are the ones in swank::dispatch-event: There's a huge destructure-case clause in it stating those commands that require no special handling, and it can't be extended. I didn't understand channels. In the mrepl case, they seem to be temporary or bound to a session. It almost seems to be what I need, but I need some help. For instance, I want to tell the editor to open a specified file and jump to the first match of a specified string, and right now I'm using the patch I sent just so I can swank::send-to-emacs/swank::send-oob-to-emacs to "support" commands other than the ones that swank::dispatch-event expects. How can I implement this request (or one like it, e.g. Lisp->Slime) using channels? BTW, slime-mrepl doesn't seem to be working, at least with ACL. Thanks, Paulo Madeira
participants (4)
-
Chris Kim -
Helmut Eller -
Paulo Madeira -
Stas Boukarev