reenable multiline history for terminals #838

Merged
merged 3 commits into from Oct 18, 2011

4 participants

@juliantaylor

Add configuration variable InteractiveShell.multiline_history.
If it is True cells spanning multiple lines will be saved in history
as a single entry instead of one entry per line, as was the case in
ipython < 0.11.
closes gh-571

@takluyver takluyver and 1 other commented on an outdated diff Oct 5, 2011
IPython/frontend/terminal/interactiveshell.py
@@ -229,6 +229,15 @@ class TerminalInteractiveShell(InteractiveShell):
# handling seems rather unpredictable...
self.write("\nKeyboardInterrupt in interact()\n")
+ def _store_multiline_history(self, source_raw):
+ """Store multiple lines as a single entry in history"""
+ if self.multiline_history and self.has_readline:
+ hlen = self.readline.get_current_history_length()
+ lines = len(source_raw.splitlines())
+ for i in range(1, min(hlen, lines) + 1):
+ self.readline.remove_history_item(hlen - i)
@takluyver
IPython member

I assume you've tested this, but surely if you remove item 41 (for instance), the item that was previously 42 is now 41? So shouldn't we just remove an item from the same slot n times?

you always remove from the end of the history so in effect its the same

@takluyver
IPython member

Oh I see. I'd overlooked that it was counting backwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@juliantaylor

please don't merge yet I noticed an issue that it deletes history when you recall history and execute it again as the its one line in history but it removes linecount items.

This can be solved by counting the times it accepts more and removing that amount of items.
I'll test that a bit and reopen.

@takluyver
IPython member

Perhaps in the interact loop, you could keep a record of the readline history length at the start of the current cell, then remove any extra entries after that.

@juliantaylor juliantaylor reopened this Oct 6, 2011
@takluyver
IPython member

Could I suggest clarifying variable names a bit, for people who read this code in the future. In particular, hlen (hlen_before_cell?), and _store_multiline_history (_replace_rlhist_multiline?).

@minrk
IPython member

Is this something that can be easily tested?

@takluyver
IPython member

I think we could test calling the function (_replace_rlhist_multiline) and checking the modifications it makes via readline.get_history_item. Obviously the actual user interaction is a bit trickier to test.

@takluyver takluyver commented on the diff Oct 15, 2011
IPython/core/interactiveshell.py
@@ -307,6 +307,9 @@ class InteractiveShell(SingletonConfigurable, Magic):
Automatically call the pdb debugger after every exception.
"""
)
+ multiline_history = CBool(False, config=True,
+ help="Store multiple line spanning cells as a single entry in history."
@takluyver
IPython member

This description could probably be clearer. We always store multiline cells in our own history; this affects what happens in readline history - the history you get by pressing up & down arrows, or using Ctrl-R.

Also, I think the config option should be on the TerminalInteractiveShell subclass (IPython.frontends.terminal.interactiveshell), since it doesn't affect other frontends.

it needs to be in core as there the history is recalled from disk and one must decide to do it line by line or per cell

@takluyver
IPython member

The code that's initialising readline should now only be run by the terminal frontend (as self.readline_use is now False for the ZMQShell).

In time, we should move the init_readline code to TerminalInteractiveShell as well. In the meantime, just to be on the safe side, we can use getattr(self, 'multiline_history', True), which will behave even if the code does somehow get run by the other frontends.

@minrk
IPython member
minrk added a note Oct 16, 2011

Instead of using getattr, let's make multiline_history a non-configurable trait on core.InteractiveShell, with a note that it should be removed when we finish getting the readline code out of the core.

@takluyver
IPython member

OK, that makes sense. Presumably then we override it with a configurable trait in TerminalInteractiveShell.

@fperez
IPython member
fperez added a note Oct 17, 2011

@juliantaylor, does that make sense? It seems that this is almost ready to go, so if you implement @mink's suggestion and make the default true (as there seems to be interest in that), this should be in good shape.

I would, however, like to see a test added. A simple test that pushes two lines of history and gets them back intact should suffice. It must be protected with a decorator so it only runs when readline is present, though.

That will ensure we don't regress on this feature again in the future...

With those changes and a test, I don't see what else would be needed and we can proceed to merge. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@takluyver
IPython member

@fperez: Since at least some people feel strongly about this, I think it's worth getting into 0.12. I don't think that's likely to be a problem - it seems to be mostly ready now, it just needs a bit of tweaking and testing.

Everyone: An important question is what the default should be. We changed to readline working line-by-line for 0.11, but a number of people have voiced a preference for the older joined-cell behaviour (see #571). I think I marginally prefer the joined-cell alternative.

@fperez
IPython member

It can certainly go into 0.12, I'd be happy to see that. Note that it currently doesn't merge, so unfortunately it's in need of a rebase. @juliantaylor, let us know if you need a hand with that.

@takluyver, as far as the default is concerned, I'm OK if we revert to joined-cell: I honestly think that the readline console is just the wrong environment for multiline work, so I don't really use it that way all that much myself. Hence I don't care too much, and I'm happy to go along with whatever people feel suits them best.

juliantaylor added some commits Sep 20, 2011
@juliantaylor juliantaylor reenable multiline history for terminals
Add configuration variable InteractiveShell.multiline_history.
If it is True cells spanning multiple lines will be saved in history
as a single entry instead of one entry per line, as was the case in
ipython < 0.11.
closes gh-571
30eccbc
@juliantaylor juliantaylor ensure history remains intact when recalling multiline entry
Remember previous history length to remove the correct amount
of single line entries
8f24302
@juliantaylor juliantaylor clarify variable names 7d6edcb
@fperez
IPython member

OK, we don't want this to linger forever, and @takluyver made a good point on IRC: multiline on is really the better default b/c recovering a block that's hidden 20 lines back is a pain otherwise.

I'm making the default be true and merging. Thanks!

@fperez fperez merged commit 7d6edcb into ipython:master Oct 18, 2011
@juliantaylor

sorry, for not reacting for a while, I had some other priorities the last few days.
Thanks for merging.

@minrk minrk added a commit that referenced this pull request Oct 18, 2011
@minrk minrk use unicode_to_str with readline.add_history
mutliline PR #838 added a call to readline.add_history, but without
the unicode/str protection used elsewhere, allowing `In[1]: u'é'` to crash IPython.

This makes the call match others in core.interativeshell.
240f077
@mattvonrocketstein mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
@minrk minrk use unicode_to_str with readline.add_history
mutliline PR #838 added a call to readline.add_history, but without
the unicode/str protection used elsewhere, allowing `In[1]: u'é'` to crash IPython.

This makes the call match others in core.interativeshell.
4e4a4c3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment