Michael Foord wrote: > Guilherme Polo wrote: >> >> * Allow running code without explicitly saving it before. This has >> been added in such way to allow the default settings to preserve the >> current behaviour. In this case when an exception occurs, the >> temporary file name is substituted by "Untitled" on the traceback. At >> some point, this option was available in the 2000 idlefork and has >> been sorely missed by those users who prefer to write little test >> routines in an edit window rather than in the shell window; without >> this capability it is distracting to have to choose a place to save a >> test file. Upon exit from IDLE the user is asked whether to save the >> file permanently. > > +1 (or more if I could)
+1 as well >> * Bring IDLE's shell forward on first thing printed to sys.stderr, >> this can only happen again after a shell restart. I consider this of >> great importance when writing programs that may open other windows, >> like a Tkinter program, or a Visual one, since the user might expect >> something to happen on that window but nothing happens because of an >> error that occurred without him noticing. As reported by Bruce, the >> lack of this feature has been a big problem in courses where novices >> write such programs and don't understand why an animation has stopped, >> because the error message is behind other windows. > > -0 (doesn't this mean having to *constantly* move the window out of the way > when your logging code causes it to jump in front of your GUI) ... which would teach users to only log actual errors to stderr. +1 >> * Terminate the server process under Windows too. On python trunk this >> is done only for platforms that support os.kill. > > +1 +1 (wasn't such a patch already submitted to the issue tracker?) >> >> * On python trunk when IDLE is configured to open an edit window, it >> also opens a shell window. This has been reverted to behave as users >> had come to expect, and because having the shell window present when >> it is not in use can be distracting to novices working in environments >> where they start in an edit window. > > -0 (the shell windows is useful!) The shell is useful, but it's annoying to have to close/minimize it when you just want to read a file or make a minor edit. Having the shell pop up is especially unexpected when using the "Edit with IDLE" Windows context menu option. The shell can always be opened with Run->Shell. +1 >> * When printing a traceback, highlight the stack traces that pertain >> to the running file and also remove the "in <module>" from them. This >> is an attempt to make easier for novices to spot probable errors in >> their own code.Highlight here simply means that it is written to >> stderr, like it is done now, and the other parts are printed to >> stdout. The effect normally is that, by default, errors in the primary >> file are displayed in red, and other call stack information is blue. > > +0 (I haven't noticed this problem but will take your word for it) I'm a big fan of the Squeezer IDLE extension, and this would break Squeezer's recognition of blocks of output / tracebacks. Such (ab)use of sys.stdout and sys.stderr is too much of a hack IMHO. -1 >> * Now "View Last Restart" shows the last non-empty instance of a shell >> restart. In some cases a VPython application may cause two shell >> restarts, one of them being after all application's output and thus >> "View Last Restart" would be of no use if it moved the view to this >> empty restart. > > +0 +0 as well, I've never used "view last restart" myself. >> If you would like to try the branch, please do a svn checkout of >> http://svn.python.org/view/python/branches/tk_and_idle_maintenance/ >> It also includes some other fixes and new features not mentioned above. I'll definitely give it a go, hopefully tonight or tomorrow after work. - Tal _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org http://mail.python.org/mailman/listinfo/idle-dev
