Hmm.. This conversation may be relevant to my situation. Debugging integration is broken for me. I use a console window on my second monitor (regular python, not ipython). Clicking the icons on the toolbar does nothing as well as my hotkey bindings. I'm going to try and go back and time and see when it broke.
On Tuesday, February 12, 2013 5:20:15 PM UTC-6, Jed Ludlow wrote: > > On Tue, Feb 12, 2013 at 2:50 PM, Carlos Córdoba > <[email protected]<javascript:> > > 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.
