On Sat, Dec 17, 2005 at 10:24:37PM -0800, Brad Beveridge wrote:
> So I thought that I'd post here to keep this particular meme going.
> I've looked at the Slime/Swank code.
> Slime frontend -
> - written in Emacs Lisp and hosted in the Emacs editor
> - introduces a new editing mode in Emacs
> - delivers s-expressions to the Swank backend via a TCP port, I guess
> that the s-exps are probably just plain text over the port (hmm,
> not quite - there looks to be 6 digits at the start which is the
> length of the s-exp)
> - processes the Swank return data
>
> Swank
> - a remote TCP/IP server that listens on (defaultly) port 4005
> - executes the incoming s-expressions and sends the result back to Slime
>
> I suspect that it ought to be pretty easy to talk to a running
> Swank-enabled image, it looks do just be a matter of sending
> s-expressions of the following form
> "000015(format t "hi")".
It's a little more complex than that, but not much. They communicate
in events; an event consists of a keyword, e.g. :emacs-rex, followed
by other data and/or s-expressions, for example (and omitting the
length part):
(:emacs-rex
(swank:listener-eval "(format t \"Hello World!~%\")\n")
"COMMON-LISP-USER" :repl-thread 5)
(I cut-and-pasted this directly from the *slime-event* buffer in
xemacs.) You can examine slime-dispatch-event in slime.el and
dispatch-event in swank.lisp for more details.
> It is probably a good idea to snoop the normal communications from
> Slime<->Swank
See the *slime-event* buffer. Watching that buffer is a great way to
learn about Slime/Swank interaction.
> As to the basic design of the Slime for Vim frontend, Larry mentioned
> writing it in Perl (Vim supports Perl as a scripting language).
> Should we consider Python? Lots of other applications embed Python,
> would we be helping other potential Lisp environments by writing the
> Swank frontend largely in Python? I don't mind either way, just a
> thought I had.
Well, I prefer Perl over Python. I know a lot more Perl than Python,
and generally prefer Perl over Python. You make some good points
about other applications, though, I must admit.
> We should aim to provide all the features that the Emacs Slime does,
> but with more Vim-like key access.
:) Interesting that you should put it that way. Part of me wants to
say, "If that's all you want, we should just work on making Viper mode
in (X)Emacs closer to Vim." That part of me has been at war (well,
"in conflict") with the part that wants to re-implement slime.el in
Perl.
The more Lisp I learn and do, the more attractive Emacs gets, as a
concept.
* Pros/cons of a Vim-to-Swank module:
- Pro: you don't have to install or learn Emacs to use Swank
- Pro: we get, as a side effect, a Perl (or Python) module to talk
to Swank
- Pro: The implementor need understand only enough of Emacs to read
slime.el
- Con: rather a lot of work just to port slime.el to some other
language.
* Pros/cons of refining Viper to look more like Vim:
- Pro: don't have to port slime.el to some other language; lots of
effort saved
- Pro: benefits the rest of the vi-using world in the rare instances
where they have Emacs but not Vim.
- Con: You do have to install Emacs to use Swank (I will admit, this
is a pretty big CON for dyed-in-the-wool Vimmers.)
- Con: No stand-alone module to talk to Swank
- Con: The implementor has to learn probably a lot more about Emacs
and its major and minor modes to add to Viper than to write a
Vim-to-Swank module.
* Aside: naming
If we do write a Vim-to-Swank module, what should we call it? I kind
of like SLIMP ("Superior Lisp Interaction Mode for Perl"), but that
works for Python, too. SLIMPL/SLIMPY?
-- Larry
--
Gardeners, where are you? http://www.frappr.com/lispgardeners
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
