Replies: 4 comments
-
Some sort of multi-line editing would make the REPL experience better, for sure. It seems like it might be a bit tricky to implement. I would probably want the parser to return some kind of error code to indicate when there is a parse error where we reached EOF unexpectedly, and then respond to that error code in the REPL by going down to the next line and continuing to accept input. Then this process could continue each time the user presses Enter -- either the code would be submitted successfully or we would go down to the next line. It looks like multi-line reading is supported in JLine 3, so we could leverage that, although it would require an upgrade from JLine 2 which we're currently using. I'm in the middle of a ground-up rewrite of the client in Go, so I'll explore options there when I get to reimplementing the REPL. In the meantime, adding multi-line support to the existing Java client would be a welcome contribution, if anyone wants to tackle it! |
Beta Was this translation helpful? Give feedback.
-
Maybe it can be taken that: if the last character of the line is a backslash, let the repl parser continue to the next line. |
Beta Was this translation helpful? Give feedback.
-
That's another possibility. And another option is to provide a separate mapping like |
Beta Was this translation helpful? Give feedback.
-
I am new to alda-lang and I was about to report the same feature request. I feel that having this support will allow much quicker iterations for coder/musicians. (Otherwise we will be forced to first save code snippet to experiment to a file, then run Some approaches to implementing (potentially relatively easily) this that came to my mind:
|
Beta Was this translation helpful? Give feedback.
-
It is really limiting the existence of complicated lisp codes in alda repl codes.
Beta Was this translation helpful? Give feedback.
All reactions