Buggy line continuation in Elixir

[alco]

Related to #1051.

iex(4)> ["a]
...(4)> "
...(4)> "
...(4)> "
...(4)> "
...(4)> ]
...(4)> "
...(4)> ]
** (SyntaxError) iex:6: syntax error before: [<<"\n">>]

IEx is waiting for all missing tokens. However, my natural reaction after forgetting to put the closing quote and seeing that it didn't help is to try to put another quote. This leads to cascading effect.

The problem is that there is no way to leave this cycle other then by entering all closing characters. I understand that this mechanism is currently used to implemented do-blocks, but it's too harsh to force the user to quit the shell if they missed some character accidentally and are confused about what's going on.

A plausible solution, in my opinion, would be to catch ^D and break out of the loop with a syntax error. Is it technically possible?

[josevalim]

A plausible solution, in my opinion, would be to catch ^D and break out of the loop with a syntax error. Is it technically possible?

Technically possible, yes. Feasible? Unlikely.

Ctrl+D is automatically handled by Erlang VM and they do not pass down such information. I am not sure about the best way to handle this. :S

[alco]

This is tricky. I see the same behavior in irb. Other REPLs don't allow malformed expressions, i.e. they treat blocks in a special way to allow them to span multiple lines, but simply writing "a is an error. Tested in python and ghci.

I would prefer IEx to have the latter behavior if we can't come up with anything better. It is assumed to be robust, it doesn't even accept a ^D. But once you've hit the cycle of line continuations demonstrated in the issue, if you don't understand what's going on, your only option is to bring down the shell.

Another option I thought of was to print a leading character after the prompt on each continuation line. This character must be somehow deletable by backspace. Then the user can simply ignore it to keep the current line continuation behavior. Or, if the user deletes the character, the current expression becomes a syntax error and we exit the vicious continuation cycle.

[josevalim]

I tried this with Ruby:

irb(main):001:0> "a
irb(main):002:0" "
=> "a\n"

It shows on the next line which character it is expecting for completion. In any case, I am fine with not allowing multiline strings on the shell.

[meh]

What about a single line special thing or something, like "#imdumb" as single thing inputted in the shell when it's waiting for other things.

[manpages]

I like meh's proposal better than the idea of printing a safeguard
character and better than catching ^D.

👍 for #imdumb :-D
On May 18, 2013 4:04 PM, "meh." notifications@github.com wrote:

What about a single line special thing or something, like "#imdumb" as
single thing inputted in the shell when it's waiting for other things.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1089#issuecomment-18100713
.

[alco]

@meh Could you give an example of your special thing? Is it like what I described in the last paragraph of my previous comment or something else?

I've tried the latest irb and it looks like WAT to me:

irb(main):001:0> "a
irb(main):002:0" ]
irb(main):003:0" :
irb(main):004:0" "
=> "a\n]\n:\n"
irb(main):005:0> ["a
irb(main):006:1" "
irb(main):007:1> 
irb(main):008:1* 
irb(main):009:1* 4+1
irb(main):010:1> ]
SyntaxError: (irb):9: syntax error, unexpected tINTEGER, expecting ']'
(irb):10: syntax error, unexpected ']', expecting end-of-input
    from /usr/local/Cellar/ruby/2.0.0-p0/bin/irb:12:in `<main>'
irb(main):011:0> [1,2
irb(main):012:1> ]
=> [1, 2]
irb(main):013:0> [1,2,
irb(main):014:1* ]
=> [1, 2]

[alco]

There is some logic of course, in the irb case, but that's too complicated.

[meh]

iex(1)> "a
...(1)> #imdumb

That would abort, obviously with another more meaningful name.

The safeguard idea is cute, but depending on the complexity of your fuckup it could end up even worse.

[josevalim]

I think #abort or #end would be good ones. What do you think?

[meh]

#end sounds good.

[alco]

I like #abort more. So, if we see this literal standing all by itself on a line, we break out from any pending block or line continuation. If we're not in block or continuation, we simply ignore it. Correct?

I'd probably make it a bit more adorned, like #abort#. So that we don't have accidental side-effects when pasting comments into iex.

[josevalim]

I'd probably make it a bit more adorned, like #abort#. So that we don't have accidental side-effects when pasting comments into iex.

If you are simply copying any code, the command #end or #abort on its own line is not going to do anything that it wouldn't do today (i.e. simply return nil). The only question is if you copy a string that contains one specific line inside it with just #abort.

Also, why do you prefer #abort? It gives the impression the whole shell will be aborted while #end feels more like an expression being terminated. :)

[alco]

To me, #abort stands for "abort/stop waiting for input". I don't want it to draw any associations with end. But whatever works best for others will work for me.

I meant an example like this one

quote do
#let's do something tricky here, then
#abort
  ...
end

Pasting this into iex would not do what the user wanted.

[josevalim]

Good example!

To me, #abort stands for "abort/stop waiting for input". I don't want it to draw any associations with end

For me, the association with end will make it easier to remember, that's why I went with it. :) That said, other options are: #END or #end-iex (which would also help solve the conflict issue above as they are more unlikely to happen).

[alco]

What about #!break ?