Multiline indicator ".." breaks copy-paste of old expressions/statements

[attah]

Describe the bug I'd like to copy and paste a previous multi-line expression/statement from my terminal history to run it again. Multi-line editing indicator ".." is inserted for every line, which is not valid syntax.

To Reproduce Copy multi-line code from terminal history, paste, run.

Expected behavior Code runs.

Affected versions OTP26

Additional context

[frazze-jobb]

Hi,

Here is some alternatives that you can try: You can go back in history either with Ctrl+p/n or search the history with Ctrl+r/s. If your terminal freezes when pressing Ctrl+s, you can disable this functionality with

stty stop undef
stty start undef

which you can put in your .bashrc or similar.

If you do not have history enabled, you can enable it with the kernel flag erl -kernel shell_history enabled Or set an environment variable: ERL_AFLAGS=-kernel shell_history enabled

The ".." are necessary to indicate whether we are still editing text, or evaluating the expression. We will try to think of a way to make this ".." redundant and remove it, but for now its the best option we have.

[attah]

You can go back in history either with Ctrl+p/n or search the history with Ctrl+r/s.

Or the arrow keys.

The shell_history will sure help, thanks for that tip. In-session history only, like what i'm used to, is very often not enough.

The ".." are necessary to indicate whether we are still editing text, or evaluating the expression. We will try to think of a way to make this ".." redundant and remove it, but for now its the best option we have.

I understand, but disagree (i guess that is implied...). I think this breakage is worse - though perhaps not with persistent history, i'll have to see. Previous multi-line commands didn't have or need this.

Maybe you could work with a column of colored spaces instead? That wouldn't be syntactically incorrect.

[frazze-jobb]

Previous multi-line commands didn't have or need this.

Not sure what you refer to, previous multi-line commands had a prompt on each line.

Maybe you could work with a column of colored spaces instead? That wouldn't be syntactically incorrect.

Yes, good idea, want to help to make a PR?

multi_line_prompt You would need to change this one, and update the tests.

[attah]

Not sure what you refer to, previous multi-line commands had a prompt on each line.

Oops - you are right. Could have sworn this used to work.

Yes, good idea, want to help to make a PR?

I'll see what i can do. Should be some mornings at work available for this. Would i need to consider dumb terminals, or once we are this far along, can i assume they speak basic escape sequences? (Edit: looks like i can...)

[frazze-jobb]

currently we do not have the multi line prompt for dumb terminals, they print the prompt on each line just like before.

[attah]

Fixed in https://github.com/erlang/otp/pull/7564 Thanks!

[frazze-jobb]

Turns out not everyone agrees on this feature in OTP and instead wants this to be an option, and ".." should be the default. So I am reopening the issue. To make the multiline prompt configurable.

[attah]

What were their motivations? I think syntactical correctness is a pretty solid and objective benefit.

[garazdawi]

I’ve always been a fan of how bash does it, that is show the .. when typing, but not when you do arrow up to view the history.

runs back to vacation

[bjorng]

I’ve always been a fan of how bash does it, that is show the .. when typing, but not when you do arrow up to view the history.

I agree. That's the best of both worlds.

[attah]

That's better than before... but it does still not fix copying from shell scrollback, as opposed to Erlang shell history. Are there any actual arguments against my solution other than personal taste though?

[dgud]

I would prefer this solution as well, I though this solution was brilliant. I don't see what the ".." gives that you don't get by the inverted colors, please enlighten me.

[frazze-jobb]

The major concern that was raised by @bjorng is inconsistencies with documentation and blog posts, were inverted colors is not as easy to achieve.

I also think that inverted colors is great and better than "..".

The advantage that ".." have over it would be consistency with how other REPLs and shells do it. I will make it configurable, and the default value can be discussed further, I may need to call for an OTB. Elixir will also be affected, and they are using ".." since before OTP26. @josevalim

[josevalim]

In Elixir, we do this:

iex(1)> 1 +
...(1)> 321
322

Making it dynamic may be a bigger ask but I would be happy enough if it was configurable to ...>. :)

[frazze-jobb]

I’ve always been a fan of how bash does it, that is show the .. when typing, but not when you do arrow up to view the history.

I guess we could redraw the prompt on submission and acceptance to remove the ".." occurances in the scrollback. But remove ".." when we look in history with arrow keys may be more difficult, since we need to decide on when an history expression is being edited and then redraw to insert the ".." prompts.

[attah]

I don't think pretty blog posts matters more than usability.

@josevalim What advantages does that have?

@frazze-jobb

I guess we could redraw the prompt on submission and acceptance to remove the ".." occurances in the scrollback.

Excellent compromise if that is possible. I did not consider that. I'm not after a specific style, i just want the functionality.

[josevalim]

What advantages does that have?

I haven't thought about pros and cons, to be honest, but the issue is that we use that notation in our doctests. If you add this to your documentation:

iex> 1 +
...> 2
3

Elixir will run and verify that snippet. Using a different syntax will cause a lot of confusion. It is the same problem as the current examples in the Erlang documentation but probably even more common in Elixir.

[frazze-jobb]

You can set the multiline prompt on command line:

-stdlib shell_multiline_promp {edlin, inverted_space_prompt}

or

-stdlib shell_multiline_prompt "...>"

You may create another M:F/1 that takes the main prompt as argument to create ...(1)>