>> I have more concrete ideas on the wiki:
>> https://github.com/asweigart/idle-reimagined/wiki

> I will comment on specific ideas in further posts here.

Comments on the items on this page.
https://github.com/asweigart/idle-reimagined/wiki/Killer-App

1. Single dual pane window. I proposed this on this list some time ago. For a wide screen, I want side-by-side, as with turtledemo. This could be user selectable. (In fact, I would like 3 panes.) The work I did with Lita Cho on
  https://bugs.python.org/issue21597
  Allow turtledemo code pane to get wider.
to discover how to make moving the sash, the divider between panes, work well enough on all systems will be directly applicable to Idle.

This and the below are a major changes that I am not sure if I would want to backport to 2.7.

2. Tabbed file editor.  Already on the tracker. needs to be added.
  https://bugs.python.org/issue9262
  IDLE: Use tabbed shell and edit windows
There is no reason particular reason to limit the tabs to editor windows. I would put all open windows on a tab instead of the taskbar. I would also use tabs with every pane.

A separate idea that impinges on this one. There are two good reasons to at least have the option of having a separate shell and user process for each editor window. First, running a file in the editor currently wipes out everything you have done in an exploratory session in the shell, like it or not, and sometimes this is a real nuisance. Second, editor completions and tool tips work best when the editor file has just been run, and can give wrong answers when another file has just been run.

3. Foreign language support. A separate page and discussion, but someone has to do some actual work.

4. Autosave.  On the tracker, as noted.

5. Pip gui.  On the tracker, needs to be added.
  https://bugs.python.org/issue23551
  IDLE to provide menu options for using PIP

6. Paste code to x. Separate page. Not sure about this. Python-list and StackOverflow both want code pasted in questions and do NOT want soon-to-go-dead links.

7. Better tracebacks. The short separate page has links to two pages with code but not examples. I might like this, but need to see it in action. The code would go in idlelib/run.py to enhance the traceback sent back to the idle shell process for display. Enhanced traceback could be an option. I suspect long trackbacks would be less of a nuisance when running code from the editor.

On python-list, I mentioned the idea of adding an 'undo output' feature that would put one back on the last statement entered, ready to edit. This would make long tracebacks less a nuisance in interactive entry also.

" When you get the "index out of range" error, Python should optionally tell you what the index value actually was." Message options are not practical. Check the tracker for an existing issue and if the there is not one, open a request.

8. Error message explanation. This seems similar to the idea I just posted. I like the idea of having clicks on uneditable text pop up an explanation, instead of having to right click and select.

9. Version mismatch. I am dubious about this. Detection without running is really only feasible with a #! line, which I don't expect beginners to use. 'Python 2' and 'Python 3' each have multiple versions. Using 'yield from' in 3.3 is just as bad as using it in 2.7.

10. Code checking.  There is a patch to run 3rd party checkers.
  https://bugs.python.org/issue21880
This is a follow up to the rejected idea of integrating pep8 specifically (issue 18704, I just added 21880 as superceder). As one can now for grep results, one would be able to jump from line numbered messages in the output window to lines in the editor.

Input at a >>> prompt is already syntax checked line by line. However, I would prefer being allowed to edit the statement instead of getting a new prompt, as in
>>> a a
SyntaxError: invalid syntax
>>>
The message should be a beep and popup that goes away easily.

Editor code can be checked at any time with Alt-x, but this makes the shell the active window. I want to change this. Switching to the shell should not happen unless one want to run the code and the syntax is correct. Some checking of lines is already done in the editor for smart indenting. I imagine we could add the same syntax check as done in the shell.

11. Tutorials. I have long thought about putting the Python tutorial in an enhanced read-only text window coupled with a shell and editor window. Clicking on ">>> code" would load "code" into the shell at the current ">>> ". Clicking on "example.py" would load example.py into an editor window. This would work best with 1 and 2 implemented.

Designing for 3rd party tutorial creation, from the beginning, is a good idea.


Minor 1. Line numbers.  Already in process, as noted.

Minor 2. Detect disk changes and reload. Notepad++ does this also, when the window is activated, except that reloading is optional, not automatic. With that variation, I find this a useful feature.


Summary: We have had many similar ideas and agree on most of the new features you listed. Many are already in progress at some stage or another. I see them as logical enhancements of Idle, not as a replacement.

--
Terry Jan Reedy

_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Reply via email to