eval multiple statements/blocks in one command

[kindohm]

Wrapped all expressions sent to ghci in a do. This now allows two things:

1. Eval all text in the buffer, which may include many Dirt/SuperDirt patterns, and send them all to ghci at once

2. Perform a multi-line eval on two or more adjacent patterns (with no empty lines between them).

[calumgunn]

Looks good to me -- and great idea on the hush mapping.

[kindohm]

found a major issue with this PR. import statements don't work in a do. I'm sure other non-Dirt code doesn't work either. I'll go back and change this so that the do syntax is added ONLY for multi-line and all-text eval.

[kindohm]

OK fixed that. import (and other) statements will now work in a single-line eval.

[yaxu]

Hmm good point, probably other things will still break, e.g. multiline 'let' statements.

[kindohm]

@yaxu yes just confirmed the problem with let. I think the only way to remedy this is to have two types of multi-line eval commands: the original as it works today ctrl+enter, and a new one that wraps the expression in a do.

perhaps we can map ctrl+shift+enter to this new do multi-line idea.

then to eval the entire file, map that to.... ???

[yaxu]

One question is, what is best for beginners? I think the do wrapping probably is, at least I've seen people get confused by multiple patterns not working when they're next to each other..

Actually how about this:

shift-enter evaluates either a single line, or a block when selected (I think this is the current behaviour)
ctrl-enter could wrap in a do, but only when the block has more than one line that has non-whitespace in column zero. I think this would catch these edge cases..
ctrl-shift-enter could then be eval whole file

[yaxu]

BTW I think adding an additional mapping for ctrl-. for hush would be great, matching behaviour in supercollider

[kindohm]

@yaxu ok thanks for the suggestion on the 0-col non-whitespace. I'll give it a try.

[kindohm]

@yaxu that seems to work, however it now requires proper indenting for any multi-line code in Atom. I think a lot of beginner users are used to not having to do proper indenting in Atom:

d1 $ sound "bd sn"
|=| speed "1 2"
|=| shape "0.2 0.8"

With the non-whitespace-in-column-zero change, the code must be changed to this in order to work:

d1 $ sound "bd sn"
   |=| speed "1 2"
   |=| shape "0.2 0.8"

I know my compositions would be affected by this. Personally I'm OK with the change, but I think a lot of Atom users might have some pains with this. I'll see if I can get some feedback on Slack (or maybe on the Lurk.org list).

[yaxu]

Hmm I think that's no good then..

[kindohm]

I think the only other option then is a new keyboard command so that the user can be explicit about the type of eval they want to perform. How about this:

shift+enter - single line
ctrl+enter - multi-line (as it is today)
ctrl+alt+enter - multi-line + multi-statement (add do and indenting)
ctrl+shift+enter - entire file (add do and indenting)

[kindohm]

the ctrl+alt+enter keymap I suggested won't work because it is already used by the eval-multi-line-copy command. how about this instead:

shift+enter - single line (same as today)
ctrl+enter - multi-line (same as today)
ctrl+alt+enter - multi-line, copy pattern (same as today)
ctrl+space+enter - multi-line, multi-block (add do indenting)
ctrl+shift+enter - entire file (add do indenting)

[kindohm]

ok, settled on these keymaps with the last commit:

ctrl+enter - multi-line (same as today)
ctrl+shift+enter - multi-line, multi-block (new)
ctrl+shift+space - all lines (new)

[telephon]

sorry to come in from the side: In sclang we are using a standard delimiter to tell the editor what we consider to be part of one bit of code. In that case it looks like this:

(
var x;
x + 3
)

ctrl-enter calls all code between the parentheses.

This makes it easy to see what belongs together.

[kindohm]

Closing this and leaving it un-merged. I don't think it's valuable, as there is existing Haskell syntax to eval multiple blocks using do. I've been using do with a lot of success over the past few months and have had no need for this Atom package feature.