Spyder: Run selection shortcut not working while focused on console

[oguzhanogreden]

While a portion of code is highlighted in Editor but the focus is on a console (Python or iPython), Run selection shortcut F9 is not running the selection. Run > Run selection menu works properly. If I am not mistaken, F9 would workas expected in Spyder 2.

Versions and main components

Spyder Version: 3.0.0.dev0
Python Version: Python 2.7.12 64 bits
Operating system: Windows 10

Dependencies

> jedi >=0.8.1 : 0.9.0 (OK)
> matplotlib >=1.0 : 1.5.1 (OK)
> nbconvert >=4.0 : 4.2.0 (OK)
> numpy >=1.7 : 1.11.1 (OK)
> pandas >=0.13.1 : 0.18.1 (OK)
> pep8 >=0.6 : 1.7.0 (OK)
> pyflakes >=0.5.0 : 1.2.3 (OK)
> pygments >=2.0 : 2.1.3 (OK)
> qtconsole >=4.2.0: 4.2.1 (OK)
> rope >=0.9.4 : 0.9.4 (OK)
> sphinx >=0.6.6 : 1.4.1 (OK)
> sympy >=0.7.3 : 1.0 (OK)

I would like to note that I am willing to try and locate (and perhaps fix) this issue myself. In case someone can reproduce this and think this can be handled by someone who's willing to get familiar with Spyder's code base, please feel free to guide me to relevant part of the source!

[ccordoba12]

I'm sorry but we changed this behavior in Spyder 3.0. Now you need to give focus to the Editor before trying to run a selection, which we think is the expected behavior by most people.

The reason is that F9 is now a shortcut that belongs only to the Editor and not to the whole application. Having the least amount of global shortcuts prevents conflicts between shortcuts present in different plugins (e.g. the Editor and the IPython console).

@jitseniesen or @goanpeca, what do you think about this?

[jitseniesen]

My first thought is to leave the F9 shortcut local to the Editor, unless there is a good argument to make it global.

[oguzhanogreden]

One case where I need this is when I am running the same block of code with, say, a option_var = 1 in the editor. If F9 is global, I can do this: 1) mark the code block, 2) hit F9, 3) type option_var = 2 in the IPython console, 4) hit F9. Then observe and decide which one to make default, for instance.

This would be my argument but I wouldn't be strong about this, I am not exactly sure if this is the best way to deal with such cases.

[jitseniesen]

I have to admit that there was an instance last week where I would have liked to have F9 be a global shortcut: 1) I ran some code from the editor 2) which gave an error because I was missing an import 3) so I switched to the console to import a module 4) and then I'd like to hit F9 to re-run the code - instead, I had to switch back to the editor and then press F9.

Nevertheless, I still feel it's better to have F9 local to the editor. But perhaps this suggests we need more flexible shortcuts, where the user can change the context of the shortcut. Thus, the user can decide to have F9 as a global shortcut, or as a shortcut in both the editor and the console.

[goanpeca]

Thus, the user can decide to have F9 as a global shortcut, or as a shortcut in both the editor and the console.

hmmm, tricky?

[Nodd]

The shortcut could be defined for the consoles and the editor, this way the shortcut isn't global but this use case works.

[gerazov]

Having F9 as global would work for me too :+1:

[ccordoba12]

Sorry @gerazov, but that's what cells are for. Please read my https://github.com/spyder-ide/spyder/issues/3344#issuecomment-237561462 above for the rationale of our decision.

@spyder-ide/core-developers, what do you think about this? I think it should be closed as "Wont fix".

[ccordoba12]

The shortcut could be defined for the consoles and the editor, this way the shortcut isn't global but this use case works.

This is the route we could take, but how to maintain both shortcuts in sync?

[bcolsen]

I haven't seen any argument here that an "up arrow+enter" in the console to run the previous entry wouldn't fix.

If it was global I would expect that it would run the selected text in the currently active pane. For example running a line of code from the history, a previous command in the console or even an example from the documentation.

[ccordoba12]

I haven't seen any argument here that an "up arrow+enter" in the console to run the previous entry wouldn't fix.

Exactly.

If it was global I would expect that it would run the selected text in the currently active pane. For example running a line of code from the history, a previous command in the console or even an example from the documentation.

Agreed. The UX would become quite more complex and confusing.

[gerazov]

@bcolsen one optimisation I would do for the console (but that might be out of Spyder's scope) is to have it always put the cursor at the end of the _whole_ code. The way it works now is it puts it at the end of the first line only. This is fine for onliners but when you wanna redo a for loop you have to renavigate the cursor each time to end of the code block.

[ccordoba12]

@gerazov, could you explain what you mean with an animated gif?

[bcolsen]

I believe he is talking about pressing up to go through previous commands.

The issue here would be if the cursor was at the bottom line, you would have to scroll through all the lines to get to the next previous command.

If I need to run more than a few lines in the console I will use codecells. You can even open a new file type your lines and hit control-enter. No saving necessary.

[ccordoba12]

The issue here would be if the cursor was at the bottom line, you would have to scroll through all the lines to get to the next previous command.

Yeah, that's rationale behind putting the cursor on the first line when moving up to browse your history: if you want to move between several entries real fast, that's where it needs to be (else it'd be really time consuming to do it).

I see no need to continue this discussion. Cells are really the way to go if you want to keep evaluating a block of code over and over again.

[gerazov]

I agree guys :+1:

[ccordoba12]

Thanks for understanding @gerazov!