Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
> Adding to what Tal said: IDLE's calltips replace some uses > of help() in standard interactive Python. For the rest, I > think being able to move hundreds of lines out of the > REPL and into a separate persistent window, which that can > be moved at least partly aside from Shell, improves IDLE's > usability for teaching. Such blobs of text make it > hard to scroll back to see previous entries and responses. I respectfully disagree. I've used IDLE for teaching over 200 days per year for the past seven years. It is becoming less and less usable and more and more buggy as it ventures beyond its original goals of being a simple, basic interactive development environment. We're still getting double and triple spacing after a syntax error and that survives a shell-restart. So, I have to close and start new session logs several times per day. The slow printing makes students think that Python is slow, so I switch to the command-line to show that the output can be almost instant. The tooltips sometimes show the print() function tooltip no matter what is being editted and it persists on the screen as your typing the whole expression. This is a significant visual distraction from the actual code. The squeezer causes frequent breaks in a train of thought because when I ask Python to display something, I then have to switch windows and click the unsqueeze. For years, I get random paste-clipboard effects in the middle of typing lines in the interactive shell session. My only defense is to type Cntl-Z to undo the splatter so that I can continue with my demos uninterrupted. I show people how to edit code in one window, press F5 to see and debug the results at the interactive prompt. Seeing both at the same time on side-by-side screens makes for an effective workflow. However, recently a student got into a new-tabbed mode and there didn't seem to be any way to turn it off. It became impossible to see code and output or error messages at the same time. This devastated the learner's experience. The redesign of the configuration fonts/tabs window was not an improvement. We need to get rid of the slider for indentation width (it attracts newcomers like a moth to flame). Instead, we need a slider for the font-size which is usually the very first thing people need to change. The giant window for font samples is cute and mostly useless. I don't know if it is possible, but it would be great to filter the font sets to only show monospaced fonts. Students setting to Arial degrade their Python experience without ever realizing why. People need to be able to edit quickly. On the Mac, Cntl-E does the right thing and goes to the end of a line, but Cntl-A goes to the beginning, even before the PS1 prompt. This a low quality experience (readline is smart-enough not to do that at the command-line). I can make a custom key set and remap Cntl-A to beginning-of-line but it is a PITA to have to get a whole classroom of people to do this every week. It should be the default. When started from a terminal session, IDLE emits some warnings such as " Warning: config.IdleConf.GetThemeDict - problem retrieving theme element 'context-background' from theme 'ttmmmmmmpp'" Note the odd theme name and doubled letters. Likewise, on the configure window for keys the custom key set name shows up as 'bbllttiinn'. I don't use this but the letters are oddly doubled there a well. Tab completion sometimes works and sometimes doesn't. When typing in text blocks (triple quoted strings) the tab key sometimes indents and sometimes starts inserting "IndexError" or some other random text". FWIW, I think the squeezer focused on the wrong problem. In general, I've never had a problem with too many *lines* of output. You can always Ctnl-C if printing a long file or somesuch. The real problem with IDLE was excessive wide output on a *single* line (i.e. look at the repr for a recently read dataset or long repr for a list). That tends to cripple IDLE because line wrap logic seems to be computationally expensive for scrolling text windows. The effect persists even after the offending text has scrolled off and is no longer visible. For feature requests, there's only a handful of things that I need to improve the experience: * Cntl-plus and Cntl-minus to change the font size. * A hotkey to clear the entire text window. * A way to make interactive prompt sessions auto-save periodically. * An easy way to turn-on and off line numbering with off as the default. I don't personally need this, but some learner will request it once each week. Some other ideas: * It would be nice if IDLE's shell session recognized when someone typed a line starting with "python" "pip" "cd" or "ls". It is common to have someone confused about bash command lines very python command lines. Two other recurring usability problems * Sometimes the search and replace dialog loses the focus and gets buried *under* editor panes. The visible pane seems completely inoperative because it is waiting on the non-pane pane to close its dialog. Ideally, active dialog windows can be forced to the top. However, if that isn't possible, at least make the window exitable by pressing ESC (which is one of things people try when their editor pane becomes unresponsive). * Likewise, when pressing F5 and a SyntaxError is encountered, a dialog window pops up that cannot be cleared with an ESC key. So users have to break their keyboard workflow and use a mouse to target a small button because turning their attention back to the screen location where the actual problem is. Hope you all find this suggestion list to be useful. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35196> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
