-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interpreter (aka REPL) history should be by statement, not by textual line. #1067
Comments
Imported From: https://issues.scala-lang.org/browse/SI-1067?orig=1 |
@odersky said: |
@paulp said: |
@SethTisue said: |
@paulp said: |
@SethTisue said: Stuff pasted into the REPL via :paste probably shouldn't become part of the history when you up-arrow through it. I'm typically pasting 5 or 10 or 20 or 50 lines of code, and it's annoying to have to up-arrow through all that stuff to get to the last expression I actually typed myself with my fingers. I can imagine this might not be totally trivial to implement since :paste'd code should certainly be considered part of the history for :replay purposes, just not for up-arrow-ing purposes. I'm adding this as a comment on this ticket, but it isn't strictly the same issue. If fixing JLine not to choke on multiline stuff is too hard, then it would still be very nice to have the "don't up-arrow into pastes" change just by itself. |
Li Haoyi (lihaoyi) said: @ trait A{
val x: String
}
defined trait A
@ <UP>
@ trait A{
val x: String
}
defined trait A
@ <ENTER>
@ It looks kind of awkward sometimes, but it does work |
Hamish Dickson (hamish.dickson-at-gmail.com) said: |
Dotty has this. Can't we steal it? |
This was contributed for free by the JLine3 community. |
If you write the following in the interpreter:
And use up-arrow (or whatever your particular binding is), you get
scala> }
Which is nearly useless. The history should instead group an entire statement. For example, in zsh, if you write:
Then hitting up arrow gives you:
rlwrap is not smart enough to either, it would probably require more configurability than is reasonable for it to offer, so we should fix the interaction with jline to get the more useful behavior.
The text was updated successfully, but these errors were encountered: