On Tue, Feb 12, 2013 at 2:50 PM, Carlos Córdoba <[email protected]>wrote:
> Today, all decisions about run commands and debugging control commands are > based upon console visibility. So, if two consoles are visible and you > change focus to the editor, commands will always go to the IPython console > regardless of widget focus today. To get them to enter the other console > you have to hide the IPython console. > > > My bad, it was the easiest thing for me to do at first. Perhaps after > solving the previous point, it should fix this one too. > > I don't think it's bad at all. It's actually quite convenient for the large majority of use cases. It only becomes a bit tricky when two consoles are visible. That's a fairly rare situation. > Incidentally, one longer-term solution would be to make it impossible > for more than one console to be showing by housing all consoles, both > standard Python interpreters and IPython clients, as tabs of the same > plugin. Old Spyder was this way. That would eliminate all ambiguity about > command direction and require no manual focus setting. I know issue 1053 > argues for putting IPython kernels and clients in the same plugin [1], but > the more I think about it the kernels are the things that really belong in > their own plugin by themselves. Standard Python interpreters and IPython > clients seem to be more natural cousins to be housed in the same tab widget > given the type of input they receive from the user. > > > Work for 2.3, right? :-) The two consoles are wildly different right now > and joining them won't be easy (if feasible at all). > Yes, I mean for 2.3 or beyond. I'm not recommending it lightly since I recognize it would be a fair amount of work. Rather, I'm suggesting that it's worth considering since it seems more intuitive than forcing kernels and clients into the same plugin (which sounds like a lot of work, too). If we are to adopt a problem that involves a lot of work, we should make sure we adopt the right one. > This will likely require a monkey patch to pdb since it's possible to put > a console into debug mode from the command line, and the only way for > Spyder to find out about that would be if pdb itself did the notifying. > That's not really a good option for external kernels since we can't monkey > patch pdb in those. I think we can come to a rational console selection > method without having to go there. > > > I think it could be far more easier: add a signal to the Debug action and > button that changes the state of a new console attribute called "debugging". > > It is possible to catch it there for many use cases, but what happens when, say, you use IPython magic from the command line and manually issue "%run -d script.py". Now Spyder has no idea that debugging is going on in that console. -- You received this message because you are subscribed to the Google Groups "spyder" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/spyderlib?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
