[Idle-dev] IDLE improvements
jason at jasondoucette.com
Wed Oct 26 05:55:44 CEST 2005
> If an existing feature isn't working, that's a bug. Adding or
> enhancing a feature is an RFE, even if it's 'expected'.
Ok, I understand the logic: Let's add more features and make it more
powerful, rather than sit and tweak each UI issue to perfection. However,
certain UI issues can be very *counter productive*, thus I would assume they
hold more 'weight'.
A quick question: Is IDLE Windows-only?
> There is already an RFE open for this request:
Note: the above URL, while logged into sourceforge, does not allow me to add
a comment. If https:// is used, instead, it works. I'm new to sourceforge,
so I didn't know what was going on at first. Just a heads up for future URL
> The OP noted that a keybinding could be added to the user's config
> which would handle the request. Raymond wants to make it the default.
> I made a comment that maybe it would be nice if IDLE worked like
> python mode (smart tab indent and backspace dedent. Note that there
> is a fairly serious bug (1179168) involving Shift-Tab keybindings
> which needs to be fixed first! (I just raised the priority.)
> The discussion ended there, but I'd be happy to pick it up again.
I certainly agree with Raymond. I am not sure what you mean by "python mode
= smart tab indent and backspace dedent", since I believe IDLE already does
these things. On that topic of smart indents, I notice areas IDLE could be
smarter in, such as when "else:" or "elif xxx:" is typed, it could dedent
>> . My guess is that the interface should be simple and
>> intuitive, and be robust enough for professionals to not be
>> frustrated with any quirks. Correct?
> Yes. More esoteric facilities could be available, but should not be
> obtrusive. (We don't want to scare the kiddies.) The experts will
> find the features! (And assign hot keys). Maybe we should have a
> "long menus" option someday which could be turned on in the Configure
> IDLE dialog. It would also be nice to have an extension config dialog.
Regarding your comment "The experts will find the features", it sounds like
you would likely disregard any UI improvements. My thought is if IDLE
worked as expected, according to standards set by other programs that most
people are already used to, then learning Python with IDLE may be more
comfortable to more users, and thus may attract more users. Is the
attraction of more users (i.e. popularity) a consideration? If so, you may
wish to hold UI in higher regards.
>> Do I submit the bugs directly to the bug tracking database, or
>> should I discuss them here first?
> Maybe we should discuss yours briefly here so we can come to agreement
> on what's a bug, what's an enhancement, and what's likely to be
> implemented (or not). Give us a quick list!
Ok. I am sorry I took so long to respond, but here's a quick (?) list:
- The cursor blinks even during motion... by far, the #1 annoyance. It
severely slows down typing speed, since you have to wait to see where the
cursor is after moving it. If you don't wait, you may start typing in the
wrong location, which requires undoing that, repositioning, and retyping -
which is worse than simply waiting, and readjusting if it is in the wrong
position. *This forces you to slow down, and thus is very counter
- If I run a .py program via double click, it leaves pythonw.exe running.
If this happens, IDLE will not start properly (with a "Socket Error:
Connection refused" error, then a "IDLE's subprocess didn't make connection.
Either IDLE can't start a subprocess or personal firewall software is
blocking the connection." error), until all instances of pythonw.exe are
- The cursor flashes when application is not in focus.
- Ctrl+C does not appear to stop the running of a command when it is
attempting to construct a string (for printing) of a large list.
- Typing too quickly means anything typed before the >>> prompt is ignored.
Example: I loaded a file into a list with l = f.readlines(), then converted
it into a set with s = set(l), then attempted to see the length of the set
with len(s). But, the letters 'len' were typed before the set(l) command
finished, thus the interpreter ran '(s)', which attempts to print the value
of s, which pretty much hangs the interpreter - I waited on my 1.5 GHz
machine for about 20 minutes (s length of 80,000) and it had not printed a
single character. Note that this occurs for the simplest commands, such as
assignments. It forces you to slow down, and thus is counter productive.
- When saving a new file, it does not append .py, unlike every other Windows
- Under 'Options', 'Configure IDLE', 'Fonts/Tabs', 'Set Indentation Defaults',
if you change the default to 'Tab key inserts tabs', this setting appears to
take place only once you restart IDLE.
- For the File Editor window, when TAB is set to insert tabs, it inserts
spaces. I realize this is known, as it is stated on the 'IDLE Description'
page. But, even if you Python source files contain 4 space indents rather
than Tabs, there is no reason the editor cannot 'think' of them as tabs, so
the user need not be annoyed with it.
- In the File Editor, if you load a text file with tabs, they will shows as
actual tabs, but they are 8 spaces large (instead of 4, the default setting
within IDLE). Pressing delete on this '8 space tab character' changes it
into 4 spaces (NOT a 4-space wide tab, but 4 individual spaces), as if the
other 4 spaces were just deleted.
- When pasting code into the IDLE editor, if the cursor is moved off screen,
the view does not change to show the new location of the cursor. Note that
this occurs when pasting a copied function from one file to another, or even
when just toying with the interpreter while learning (during which the
cursor is almost always at the bottom of the screen).
- Right clicking on a .py file, and selecting 'edit with IDLE' loads a NEW
copy of the shell, instead of just opening it in the existing instance.
- When pressing Ctrl+H to do a search and replace, or Ctrl+F to do a search,
the 'Find:' field is not automatically populated with the current selection.
- The buttons within the search dialogs are not standard. The 'replace'
button should do what the 'replace + find' does. The Alt+F and Alt+R
shortcuts also do not work.
- In the python.org tutorial, "6.2 Standard Modules", after "import sys",
the commands "sys.ps1" and "sys.ps2" do not work in IDLE, only in the
command line. The text states that "These two variables are only defined if
the interpreter is in interactive mode", so is IDLE not in interactive mode?
I thought the fact you can use it as a calculator and such means that it's
in interactive mode.
- IDLE appears to get slower as more text is drawn within its window. You
can notice that the program is slow merely by grabbing the window and moving
it about the screen. It updates about 1/10th the speed of most windows.
- Alt+Back Space does not perform 'Undo' (Ctrl+Z), but performs 'Back Space',
- It would be extremely helpful if, when typing the 'else:' clause on a new
line that it would automatically remove the indent, much like MS's Visual
Studio does as soon as you type the colon within a switch statement.
- When moving the cursor up/down, the status bar display for the line number
does not update until the cursor movement stops. You cannot see where to
stop on a particular line that the interpreter is complaining about easily.
Yes, I know about Alt+G, but you may only be a few lines away and choose to
use the cursor instead.
- Alt+G, for 'goto line', should be Ctrl+G.
- Ctrl+G in IDLE is the 'Find Next', where the standard for Windows apps is
- It would be nice if the HOME key, within the shell, would return you to
the end of the prompt (where you would start typing), rather than the start
of the entire line (the beginning of the '>>>', which means you have to
manually step past it).
- It would be nice if pressing the HOME key went to the first character that
is not whitespace. Then, if pressed again, will go to the first character
on the line. MSVC++ does this, and it is quite convenient when you want to
move to the beginning and not have to step through spaces (especially due to
the lack of tabs).
- From the "IDLE Description" page: "However, if you paste in a selection
containing more than one Python statement, only the first statement will be
sent to the interpreter when you press Enter." It would be nice if this
were not the case, so newbies could copy and paste sample code from
- Function/Method Call Tips that show what parameters a function/method
requires will disappear after you enter the closing parenthesis, but it
remains if you remove the opening parenthesis instead -- such as if you
decide to not use that function/method and begin typing completely different
- The 'Path Browser' shows only what sys.path equals at the start of the
shell, not what it equals at the current time. This is annoying because: 1.
you cannot change it, and then use the Path Browser, and 2. because IDLE
does not run the start up file that the 'PYTHONSTARTUP' environment variable
- File -> Open does not remember the last directory accessed.
- For some bugs in IDLE, it has been suggested to try different switches.
However, the shortcuts made do not show the command line. It is hidden.
The 'Find Target' button is grayed. Apparently this is called 'resiliency'
but it is bad, since users have no idea what command line is, so they can
- It would be nice if Ctrl+W selected a whole word, as in MSVC++. However,
understand that this is the same shortcut to close a web browser window in
IE and Firefox. It's a bad shortcut, yes, but it is widely used by a lot of
- The search and replace dialog does not highlight the text it finds
sometimes. In particular, this happened when searching for 'print' to
replace with '#print'.
- When you have a non-ASCII character in a file, and attempt to save it (by
clicking save, or by trying to run it, when saves it first), the warning is
very unintuitive. Pressing 'Edit my file' seems to allow you - the human -
to edit the file before saving, so you can add that text to the top
manually. This is not the case, it edits and saves it for you.
- Alt+O is the shortcut for both the 'Format' menu and the 'Options' menu.
The standard would be to leave Alt+O for Format. Something else needs to be
set for Options. Note that this means the main shell window will also have
to change. BUT, it does not have a Format menu, but it has an Options menu,
thus people may wonder why Alt+O isn't attributed to Options. Perhaps the
Options menu should be called something else, or its sub items be moved
- The Insert key does not alter an insert/overwrite state.
- There is no horizontal scroll bar.
- Under the file menu, the 'close' (ALT+F4) and 'exit' (CTRL+Q) selections
may not be intuitive. It seems that when you open a new window, you should
be able to close it by pressing ALT+F4, or by selecting the last selection
in the file menu. For instance, I routinely press ALT+F to select the 'File'
menu, then press up, to select the last item, and press ENTER to exit.
Making things standardize avoids ALL possible issues with ALL the different
ways users go about doing things. When I press ALT+F and UP and ENTER, I
don't think 'I am selecting the last menu in the file list', I am thinking
'close this', and my fingers do something really quickly without conscious
thought, then it closes. When I decide to close a new window in IDLE, my
fingers do something that makes the whole application shut down.
- If a module is changed, no recompile is made when a file that uses it is
run. The compiler does not check to see if the .py file is NEWER than the
.pyc file. I have to specifically run it when the changes are made to force
> In general, putting specific requests on the Trackers is better so
> they don't get lost and can be tracked ;-) Sometimes a quick question
> here can save time in the case of enhancements, but if it's a
> reproducible bug it belongs on the tracker.
> Please look over the IDLE bugs, patches, and RFE so you don't
> duplicate them. You can limit the tracker to IDLE by using the
> Category selector.
> General discussions of developmental direction and problems which are
> still vaguely defined are good topics for this list.
Ok, thanks for all of your information. It is appreciated.
Jason Doucette / Xona.com
www.jasondoucette.com / www.xona.com
More information about the IDLE-dev