[Idle-dev] IDLE improvements

[Jason Doucette]

Kurt,

> 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:
> http://sourceforge.net/tracker/index.php?func=detail&aid=694339&group_id=5470&atid=355470

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 
postings.


> 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 
automatically.


>> . 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 
productive.*

- 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 
shut down.

- 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 
application.

- 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', 
instead.

- 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 
F3.

- 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 
tutorials easily.

- 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 
code.

- 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 
points to.

- 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' 
( 
http://mail.python.org/pipermail/python-bugs-list/2005-March/027966.html ), 
but it is bad, since users have no idea what command line is, so they can 
modify it.

- 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 
people.

 - 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 
elsewhere?

- 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 
a recompile.


> 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