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 _______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
