Keybinding: Send selected form to REPL

[mbossenbroek]

Would it be possible to add a keybinding for 'Send selected form to REPL'?

It's somewhat confusing to have to place the cursor before the selection for it to be evaluated. For example:

[:bar (foo 42) :baz]

In this case, with the middle form selected and the cursor after it, I would expect that to be sent to the REPL.

Secondary question: what's 'Execute Current Statement', if not to send it to the REPL? Sometimes it inserts a return before the selected lines, sometimes it replaces them.

[cursive-ide]

When a form is selected, both "Send top form to REPL" and "Send form before caret to REPL" will send the selected portion, not the form they would otherwise choose. Does that do what you want?

Execute Current Statement is a source of endless confusion, sorry. It's the action that sends what you're editing in the REPL editor to the REPL, i.e. it only works in the context of the REPL editor. Previously it was hard-coded to Ctrl-Enter on Win/Linux and Cmd-Enter on Mac, but people who switched OSes wanted to be able to customise the keybinding so they didn't go crazy. In order to do that I had to expose the action but it's not clear that it's only available in that context. I'll think about whether to rename it to try to make that clearer, or whether it should perhaps execute "Send form before caret to REPL" in a normal editor. The issue is that in the normal editor that key is already bound to another action, and if I make users change the keybinding there so that it doesn't conflict (because they're used to the existing behaviour) that will also change the key they have to use in the REPL to send their forms.

Somewhat related to #1225.

[mbossenbroek]

Ahh - that works if you're not on the last form in the file. If you have the last form selected, with the cursor at the end, it doesn't seem to do anything.

re: 'Execute Current Statement', I think you did explain that before, but it got me again :)

Which reminds me... If you are in the REPL, it seems that if you type a partial command and hit Enter, it sends the partial command to the REPL. For example, say I type this:

(let [x 42]

... and then hit enter. It sends that line to the REPL, and now I can't edit it anymore. And I have to complete it. Is there a mode that allows for multi-line REPL input? Something that would only send a completed form when I press Enter at the end of the form?

[mbossenbroek]

Ok, played around with this some more...

When using 'Send top form' and the form is in the middle of the file, it does the right thing if the cursor is before or after the form.

When using 'Send top form' and the form is at the end of the file, it does the right thing if the cursor is before the form, but does nothing if the cursor is after the selected form.

When using 'Send form before', this only works if the cursor is at the end of the selection. When the cursor is before the selection, it does nothing. When bound to Cmd+Enter, it also inserts a newline before the selected form, but doesn't send to the REPL.

[cursive-ide]

Thanks for that investigation, I'll get all that fixed.

Re: your question about partial commands - I always forget that people who don't have their parens closed automatically can also be productive members of society :-)

So... it used to work as you describe. However there's an ongoing issue with the Cursive REPL when the user wants some input using read-line or something. Currently that is difficult and doesn't really work properly because editors in IntelliJ are "strongly typed", i.e. the REPL editor is a Clojure editor and will complain if you put anything else in it. It mostly works if you only entered numbers or short bits of text, but then the behaviour you asked for above becomes an issue since you couldn't send them unless they were valid Clojure code. So I disabled that, which mostly works for everyone except the few dinosaurs users who don't have their parens closed automatically (since if you do, the caret is not at the end of the form). The real fix is to allow the user to swap the editor for a text one somehow, which is really a pain - I can't come up with a decent UI for that. Once I get that worked out, I can restore the behaviour you want. Let me think about this and see if I can come up with a fix.

[mbossenbroek]

Ahh - that makes more sense. I only recently switched off the automatic brace matching because it was frequently doing the wrong thing and was fairly annoying. I would rather have to close them myself 100% of the time than have to guess what the behavior will be while I'm typing. I don't think this has anything to do with cursive - it seems more like intellij flakiness. FWIW, that request is much lower priority than the other stuff I've been asking for :)

[cursive-ide]

Ok - I'm interested in any flakiness there, if you have any examples I'd very much like to see them. There are also a surprising number of config items around that so you may be able to fix it with a flag depending on what you were seeing.

[cursive-ide]

Ok, I think I've fixed everything here, except the read-line issue:

1. Send top form should now do the right thing in all cases.
2. Send form before likewise now works with any selection.
3. While digging around the "Execute Current Statement" thing, I found that there's actually a built-in dummy IntelliJ action called "Execute Current Statement in Multiline Console". The idea is that individual language actions just use the shortcut assigned to this action, so this is what Cursive now does. So "Execute Current Statement" is no more and hopefully things will be less confusing.

[cursive-ide]

Oh, and again, I'm very keen to receive issues about paren-closing weirdness - I definitely want to fix those if possible.

[mbossenbroek]

Awesome! Thanks for the quick fix. I didn't have time yesterday to play around with the parens, but I should be able to make some time today.

[mbossenbroek]

Ok, got one. Say I’m creating a new anonymous fn at the bar:

(foo |)
(foo #|)
(foo #(|)
(foo #()|
(foo #())|

If I open a paren after the hash, it doesn’t produce the matching one. Then if I type the closing paren, it thinks I just wanted the original closing paren, so I have to type the closing one twice.

HTH

-Matt

On April 27, 2016 at 2:00:26 AM, Colin Fleming ([email protected]) wrote:

Oh, and again, I'm very keen to receive issues about paren-closing weirdness - I definitely want to fix those if possible.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub