Skip to content
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

Can't traverse console history for commands longer than 1 line #5935

Closed
Rob-Welch opened this issue Dec 9, 2017 · 7 comments
Closed

Can't traverse console history for commands longer than 1 line #5935

Rob-Welch opened this issue Dec 9, 2017 · 7 comments

Comments

@Rob-Welch
Copy link

Description of your problem

Any command in the IPython console longer than one line will stop the user from going back through the console history (not ones with line breaks - just something long that overflows to two lines). Even if they manually reposition the cursor at the end of the line, it won't go back. If they manually position the cursor at the start of the line, it will, but that now filters alphabetically or something.

What steps will reproduce the problem?

  1. Open an instance of the IPython console.
  2. Type a console command longer than one line (hitting f5 will make a runfile long enough in many cases)
  3. Try and use the up arrow key to navigate through your console history

What is the expected output? What do you see instead?
Expected: go back through history.
What happens: the cursor moves to some part of the second line of the command and stays there.

Please provide any additional information below

Versions and main components

  • Spyder Version:3.1.4 (although I think I've seen this on a few later versions)
  • Python Version:2.7.14
  • Qt Version: 5.9.1
  • PyQt Version: 5.7
  • Operating system: Ubuntu 17.10

Dependencies

jedi >=0.9.0 : 0.10.2 (OK)
matplotlib >=1.0 : 2.0.0 (OK)
nbconvert >=4.0 : 5.1.1 (OK)
numpy >=1.7 : 1.12.1 (OK)
pandas >=0.13.1 : 0.19.2 (OK)
pep8 >=0.6 : 1.7.0 (OK)
psutil >=0.3 : 5.0.1 (OK)
pyflakes >=0.5.0 : 1.5.0 (OK)
pygments >=2.0 : 2.2.0 (OK)
pylint >=0.25 : 1.7.2 (OK)
qtconsole >=4.2.0: 4.2.1 (OK)
rope >=0.9.4 : 0.10.5 (OK)
sphinx >=0.6.6 : 1.5.6 (OK)
sympy >=0.7.3 : 1.0 (OK)

@CAM-Gerlach
Copy link
Member

I can confirm have experienced this in many cases on Spyder 3.2.3 - 2.3.4 on Windows, as well, and it indeed is a major frustration.

@ccordoba12
Copy link
Member

That was fixed in qtconsole 4.3.1, I think. Please update and try again.

@CAM-Gerlach
Copy link
Member

CAM-Gerlach commented Dec 10, 2017

@ccordoba12 Okay, so with qtconsole 4.3.1, using up arrow (down arrow) before hitting any other key after navigating to a statement, multiline or single with up arrow (down arrow) will go to the previous (next) statement, However, if this is not the case, buggy and inconsistent behavior (between up/down, with no apparent motivation) occurs:

  • IF the {up/down} keypress is the first keypress since the current statement was arrived at (e.g. by up or down), AND the cursor is already on the first last line, THEN it goes to the {prev/next} statement
  • IF a statement was arrived at by up/down AND the user continually pressed down/up, THEN go to the {previous/next} statement [Note: This includes when down is pressed after having gone to a previous multiline statement, and the first line is not longer than the last] UNLESS (the key pressed is up AND the first line of the statement is longer than the last line [i.e. the cursor, having started at the end of the last line, doesn't end up being at the end of the first line when up is pressed]) do nothing
  • IF the keypress is down AND cursor is on the last line [including if left and right have been pressed previously] THEN go to next statement UNLESS up has been pressed at least once on the first line after arrival at current statement (and the press of another key, which blocks it from actually going to the previous statement), THEN do nothing [in this case, single or multi line, it is impossible to go to the next statement at this point no matter where the cursor is placed, unless and until the cursor is moved to the first char of the first line and up is pressed to go to the previous, then down starts working agian (next example)
  • IF the keypress is up and the cursor is at the first character of the first line, THEN go to previous statement [always]
  • IF the keypress is up AND only up has been pressed since arrival at the current statement [no left/right] AND the last line is not longer than the first (i.e. the cursor is then by default at the end of the first line after pressing up repeatedly) THEN go to previous, ELSE do nothing

In all of these cases, I see no reason why both up/down should consistently move to the previous/next as long as the cursor is anywhere on the first/last line, and not stop working arbitrarily. In fact, to deal with the case of having to scroll through an entire multiline statement to change direction even if all this does work (if it didn't, things get even worse), I would suggest that Ctrl-Up/Down would always skip the the previous/next statement regardless of the current line the cursor is positioned in a multiline, as they currently have no apparent function in qtconsole and this is a frequent annoyance in my work.

So, should I post this as a new issue in the qtconsole repo? Or what would you suggest? Thanks.

@Rob-Welch
Copy link
Author

I can confirm that the issue no longer applies with qtconsole 4.3.1. Thanks for the help!

However, I agree with @CAM-Gerlach that the behaviour still a little inconsistent. In particular, if you press left or right in the middle of a multiline statement, up/down do nothing (not even change the line) unless you set the cursor to the very first character of that statement, in which case you can only go up.I also checked in IPython-qtconsole and the behaviour is the same there - but it's not as apparent, because in regular IPython, you don't tend to call runfile with very long parameters.

In general I like the IPython console. However, these issues, combined with the lack of autocomplete, have kept me from upgrading to Spyder 3.2 and losing the regular Python console.

@ccordoba12
Copy link
Member

So, should I post this as a new issue in the qtconsole repo?

Yep, please do it @CAM-Gerlach. Thanks!

@ccordoba12
Copy link
Member

I can confirm that the issue no longer applies with qtconsole 4.3.1. Thanks for the help!

Great! Closing this one then.

In general I like the IPython console. However, these issues, combined with the lack of autocomplete, have kept me from upgrading to Spyder 3.2 and losing the regular Python console.

The Python console had a simpler design, e.g. it couldn't complete multi-line statements. Besides, autocomplete works just fine in the IPython console, the only problem is that it's not automatic, you need to Press Tab to get it.

@CAM-Gerlach
Copy link
Member

Yep, please do it @CAM-Gerlach. Thanks!

Created as #259 on the qtconsole repo.

In general I like the IPython console. However, these issues, combined with the lack of autocomplete, have kept me from upgrading to Spyder 3.2 and losing the regular Python console.

Somewhat relevant/addressing this: issue #5759 and PR #5878

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants