REPL capability plans

123 views
Skip to first unread message

Chas Emerick

unread,
Jun 4, 2013, 2:32:28 PM6/4/13
to vimcl...@googlegroups.com
Hi all,

I've been using fireplace (and recently/occasionally, redl) for 6 weeks or so with reasonably good results. Thanks to all that have contributed to making these tools possible.

There are some areas where they fall short though, and I thought I'd drop a message here to kick off some discussion of potential solutions. The two biggest issues that impact my usual workflow are:

1. REPL interactions are strictly synchronous
2. Only one REPL session may be maintained per project

There are other items that are less significant and likely just local enhancements (e.g. support for the load-file op and such); these are just the deepest limitations of the existing tooling that span multiple concerns of architecture, user interface, and perhaps specific projects' objectives. I'll assume the use cases and rationale for addressing them (somewhere) are self-evident (if not, I'd be happy to expound on them).

After a discussion with Tim Pope via irc some weeks ago, it seemed like the most tangible thing that could be done to address #1 would be to push all of the nREPL connection/session management into a Python module, which could pling data into vim upon receiving responses from REPL request messages, sidestepping vim's synchronous nature entirely. To that end, I wrote https://github.com/cemerick/nrepl-python-client, which has much of the raw materials to accomplish this, including a "watch" facility that should make it fairly easy to attach vim-targeted "handlers" to an nREPL connection's incoming messages so that e.g. messages related to different sessions can be piped to different vim buffers.

Given fireplace's current arrangement, I suspect #2 is almost entirely a UI/vimscript matter: how and where to track each connection/session, how to expose and manage them in the UI, etc. The details of this presumably depend significantly upon how #1 is resolved, since some major internal reorganization will be necessary there.

I'm happy enough to start whacking away a patch for fireplace, though it will be weighty, and likely a breaking change for e.g. redl and other tools. I'd much rather pass nrepl-python-client over to people that are already familiar with hacking vim and have similar objectives to mine (and I'll obviously gladly help however I can in simplifying APIs and such for use from vimscript), though I recognize that the intersection of those populations might be small. ;-)

Thoughts?

Cheers,

- Chas

Darrick Wiebe

unread,
Jun 4, 2013, 10:26:21 PM6/4/13
to vimcl...@googlegroups.com
I've used fireplace extensively for a few months now and am very happy with it. Actually I love it!

The number one problem that I've run into is that I have no way to stop a running command. For example if I were to evaluate ((fn [] (recur))) in the repl, I could press C-c to stop it, but if I evaluate it from fireplace, C-c seems to only disconnect vim from the pipe waiting for the result. To actually stop my laptop from hovercrafting itself off the desk I need to kill the whole repl process, restart it and reconnect vim to it.

Perhaps someone has a solution to this that I'm unaware of, but if not I would love to see this issue addressed.

Thanks!
Darrick

Chas Emerick

unread,
Jun 5, 2013, 3:22:27 AM6/5/13
to vimcl...@googlegroups.com
Darrick,

Right, this is a symptom of issue #1 that I mentioned.  Because the entire vim process is blocking on receiving the (at least partial) response from a REPL interaction, there's simply no way for you to request an interrupt of the evaluation or other operation being performed.

- Chas
--
You received this message because you are subscribed to the Google Groups "vimclojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vimclojure+...@googlegroups.com.
To post to this group, send email to vimcl...@googlegroups.com.
Visit this group at http://groups.google.com/group/vimclojure?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Reply all
Reply to author
Forward
0 new messages