Emulated Lua shell doesn't allow multiline input

[SoniEx2]

e.g. type this in one line at a time, both in the Rio Lua REPL and the emulated Lua REPL.

do
local a = 1
local b = 2
print(a+b)
end

[payonel]

the new term code (which was just merged) is very close to allowing this, but I have two choices

1. breaks cursor movement and completing the input (enter) also confuses where the cursor should move to. The solution is somewhat costly, I'd have to add a lot of logic into cursor movement checking for \n in the data -- it's obviously doable
2. act more like traditional shells that don't allow moving cursor back UP a line, this is actually VERY simple to implement from the current state of term: https://git.io/v21UF

If you are okay with # 2, I'll PR it. Note, to use this multi-line input, you use shift+enter

[payonel]

hmm, this is more complicated than i thought, I need to consider mid-line shift-enter, to cut the input into two parts at the cursor. well........this is a start.

[SoniEx2]

Do it like Rio Lua.

[payonel]

Are you asking that we parse each line and move to n+1th line if the input wasn't complete? Um, no thanks...? At least, not at the OpenOS level that I am more concerned with.

Now again, for multiline term.read(), that's very doable, and I'm considering making it fully work with line splitting.

[SoniEx2]

I don't want multiline term.read. I want multiline Lua REPL. Re-read the issue.

[payonel]

I see. I'm not in favor of repl like multiline behavior. My point still stands that allowing multiline for shell input at the term.read() level would be cool. But it sounds to me like you're saying that would be a separate issue/feature request.

note: i don't mean to imply i make these decisions. but being that i'm not in favor, i'm not going to do it out of my own initiative, but would if I was told this was needed.

[fnuecke]

If it's not a major effort, I suppose multiline in term.read in general could be an interesting feature. Adding a custom line reader for lua.lua or hacking term.read as a special case for it doesn't seem like a good idea.

[SoniEx2]

No you don't understand.

It should read a line, if the line is incomplete it should read another line, and so on until it's complete.

Reading a line uses standard term.read(), checking whether to read another line or not would be done by lua.lua. Rio Lua uses standard ncurses line read and then checks that stuff. See here.

[payonel]

@SoniEx2 thanks for the explanation. Let me know if I understand your intent

1. leave term.read() alone
2. read additional lines of input in the lua interpreter if the command is incomplete, as demonstrated the source you linked.

My position is that I don't want this behavior. On a separate issue -- but related to this -- is supporting multiline input in general. Perhaps our discussion of multiline input via term.read should not have hijacked this thread. Unless @fnuecke wants this added to lua.lua, I feel we can close this issue.

[SoniEx2]

@payonel Maybe you should use your real Lua REPL more often. Then you'll start to miss it in OC and stuff.

And trust me, multiline input, or more specifically being able to use locals in the REPL, is a really nice feature.

A mostly useless feature would be the _PROMPT and _PROMPT2 globals in the REPL. (check the latest post in the Lua mailing list for this one)

[gjgfuj]

You can use locals in the repl just fine?

On Thu, 3 Mar 2016 7:12 am Soni L. notifications@github.com wrote:

@payonel https://github.com/payonel Maybe you should use your real Lua REPL more often. Then you'll start to miss it in OC and stuff.

And trust me, multiline input, or more specifically being able to use locals in the REPL, is a really nice feature.

A mostly useless feature would be the _PROMPT and _PROMPT2 globals in the REPL. (check the latest post in the Lua mailing list for this one)

— Reply to this email directly or view it on GitHub https://github.com/MightyPirates/OpenComputers/issues/1662#issuecomment-191406410 .

[SoniEx2]

Multiline. Remove the do/end from my original example. Useful for pasting whole programs in the REPL.

[dgelessus]

As a Python person, I would appreciate automatic line continuation in the REPL, even if it only consists of detecting incomplete code blocks and prompting for more lines until it's a valid code block. (I'm not sure how difficult this is to detect for Lua syntax - Python's REPL has it a little easier, unless there are any unbalanced parens/quotes it takes two newlines as "end of multiline statement".)

Though support for real multiline input would be nice, i. e. when cursor is at position 0 in a line and you press left, it jumps before the last character of the previous line, if that line is part of the same multiline input. (Almost no real programs with a console interface support that.) Using the up and down arrow keys for multiline cursor movement might interfere with input history.

[SoniEx2]

Rio Lua's REPL apparently just detects <eof> in the syntax error string. This is better than having a whole custom parser or adding it as part of the built-in parser.

It's also trivial to implement. Please @fnuecke?

[payonel]

@SoniEx2 note that you can already paste in multiline from clipboard. the prompt line gets a bit confused about where it should next update, but the whole clipboard gets copied and returned from term.read

[SoniEx2]

Uh, that sounds like it shouldn't happen...

No line buffering? Maybe a real PC is still way too much better than an OC computer.

[payonel]

You're welcome to work on the code and submit PRs to improve it.

As for buffering, term.read() buffers everything until the user presses enter. Parsing for newlines from the clipboard, buffering for each line, and returning only the first line, is more work that just buffering everything until enter is pressed. Yes, I have interest in making term.read() persist buffered data to allow it return the next line, and so on, but this would increase the memory footprint of the term lib and this feature was not in scope for 1.6. I didn't see much value add in doing this. There are a lot of great things we're adding to OpenOS, they have priorities.

[SoniEx2]

\n should be indistinguishable from enter.

[payonel]

But it isn't, specifically when it comes from the clipboard.