[Idle-dev] Re-imagining Idle, Killer App
Terry Reedy
tjreedy at udel.edu
Mon Apr 6 00:28:35 CEST 2015
>> 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
More information about the IDLE-dev
mailing list