REPL: my down arrow is broken

[timholy]

After doing a Ctrl-r search, I'm used to being able to hit the down arrow to go on to the next execution line. Doesn't seem to work on current master. (It's amazing how much I miss this feature.)

[Keno]

I think this is probably the prefix search thing (which I also don't like). To fix, put this in your .juliarc.jl

const mykeys = {
    # Up Arrow
    "\e[A" => (s,o...)->(LineEdit.edit_move_up(s) || LineEdit.history_prev(s, LineEdit.mode(s).hist)),
    # Down Arrow
    "\e[B" => (s,o...)->(LineEdit.edit_move_down(s) || LineEdit.history_next(s, LineEdit.mode(s).hist)),
    # Page Up
    "\e[5~" => (s,o...)->(LineEdit.history_prev_prefix(s, LineEdit.mode(s).hist)),
    # Page Down
    "\e[6~" => (s,o...)->(LineEdit.history_next_prefix(s, LineEdit.mode(s).hist))
}

Base.active_repl.interface = REPL.setup_interface(Base.active_repl; extra_repl_keymap = mykeys)

I also think we should restore this as the default.

[timholy]

I haven't followed the changes closely enough to understand if there's a good alternative already in place.

[timholy]

But thanks for the tip.

For anyone else who tries this: need to add Base. in front of LineEdit and REPL.

[blakejohnson]

We can also just bind up and down arrows differently in the ctrl+r search mode. It definitely doesn't make sense to do prefix searching there.

[blakejohnson]

Well, now I am not sure what the issue is. We already provide a custom keybinding for up/down arrows in search mode. But, they are not working. So, something else seems to be broken. I'll look into it further.

[blakejohnson]

Well, I said the custom keybindings are not working (referencing the described issue), but I cannot actually reproduce the bug. @timholy can you be more explicit about what behavior you are expecting?

[timholy]

Sure (try this on 0.3 for reference)

julia> x = 5
5

julia> y = x+3
8

julia>

Now quit Julia, restart it, and hit the up arrow twice. (You should be on x = 5.) Hit enter. Now hit the down arrow. You should get y = x+3, but instead it's just a blank line.

A similar effect can be seen with a Ctrl-r search for x = 5; again after executing it, down-arrow should bring you to y = x+3.

[blakejohnson]

I see. I was not aware of that behavior. I think we can fix this by special casing the prefix search on an empty line, and calling the normal history search in that case. I'll see if I can get that working later today.

[timholy]

It's not easily discoverable, but once you know about it, it changes your life.

[blakejohnson]

So, my fix that Jeff just merged will cause both up and down arrow to resume from an accepted history entry. I think the old behavior only did this for down arrow. Was that intentional?

[kmsquire]

I noticed that too. Yes, I believe it was intentional. Or at least, that was the behavior I came to expect, and it felt right.

[StefanKarpinski]

It was only intentional in as much as it was really hard to make readline do that. This seems better although it's possible some more clever mental model is possible too.

[timholy]

This is probably a dumb question, but here's something that's bugged me about reverse search. Say I have this on my history:

com1 stuff
com2 other stuff
com3 yet other stuff
com1 stuff
com2 broken stuff

Because com2 broken stuff messes something up, I'd like to go back to com1 stuff and then start hitting down arrow. But Ctrl-r search, if it finds com1, does not seem to like to go back to the previous com1 if it's identical; a second Ctrl-r looks for a different command starting with com1. That's nice too, but sometimes you just want to find the previous instance in the sequence.

[blakejohnson]

@timholy I guess it's debatable whether that is a feature or bug of ctrl+r search. Both behaviors are certainly possible.

[timholy]

I think it's mostly a feature, but occasionally one wants the other behavior.

[JeffBezanson]

This is still not working properly. When you're in the middle of the history, commands you re-run get appended to the end of the history, so you can keep hitting down-enter forever. I don't think we used to do this.

I also ran into a case where an input was deleted while testing this history behavior, but I'm struggling to reproduce it. I know it happened though.

[JeffBezanson]

Ok, I'm not totally sure about the deletion part. The input I wanted might just have been difficult to navigate to due to the other behavior.

[blakejohnson]

I'll look into the old behavior of where input gets inserted into history. It has to do with the save_idx input to history_move(), which so far we have just let take its default value in the prefix methods.

[carlobaldassi]

When you're in the middle of the history, commands you re-run get appended to the end of the history, so you can keep hitting down-enter forever. I don't think we used to do this.

I think we did, actually.
It's also not bad, since you can replay some history omitting some commands, after which the tail of your history will have the "latest version" of your workflow. I happen to use this quite often.

[timholy]

Likewise. You can have a nice loop running:

reload("MyBrokenModule")
MyBrokenModule.testsomething()
# drat, still broken, make more changes
# down-arrow:
reload("MyBrokenModule")
# down-arrow:
MyBrokenModule.testsomething()
...

Enough fun for a day's entertainment for the whole family.

[JeffBezanson]

Ok this is not so bad then. One more thing: after selecting an item from the middle of the history, then hitting down arrow all the way to the bottom, it ends on the last input, where it used to give you a blank line. If you want to enter something new you have to delete the input. I'd rather have the old behavior here.

[prcastro]

Also, when I go up, the cursor ends at the begining of the line, not at the end as it used to.

[JeffBezanson]

I find that I can't move down in the history past a multi-line input, and it's getting really annoying.

Also I'm certain I've hit cases where history items were deleted, but I don't yet have a key sequence that reliably reproduces this.

[tkelman]

The scrolling behavior on master right now is bugging me too. It does what I want more often if I try to train my fingers into using pgup/pgdn instead of arrow keys.

[blakejohnson]

So, one possibility to fix this is to adopt a modal behavior like ipython. Up/down arrows initiate a prefix search, but the cursor is then moved to the end of the line. Pressing up/down again "scrolls" through the prefix search results, while pressing anything other than up or down restores standard cursor movement. If people like that behavior, I would be happy to look at implementing it.

[prcastro]

Despite the implementation details, isn't this exactly how it works on v0.3?

[blakejohnson]

This can probably now be closed. Regarding Jeff's last comment about history being deleted, I wonder if what is actually going on is that the history item he is trying to find is "hidden". The prefix search has a behavior that it skips history items that are identical to the current input. While this might be nice in some situations, it does have the side effect that it can make a section of history non-navigable because it is bookmarked on either end by identical lines. So, perhaps it is time to remove that "feature".

[timholy]

I wonder about that too. I can see how it's useful sometimes (and maybe I don't notice how often I like it), but many times I've been frustrated by it. To me it seems quite reasonable to experiment with what it's like to live without it; we're still early in 0.4, so now's a perfect time to try.