[Idle-dev] New to IDLE, my wish list and, maybe, bugs.

[Tal Einat]

On Nov 1, 2007 8:42 PM, Jonathan Cronin <jcronin at egh.com> wrote:
> IDLE wish list and maybe, bugs.
>
> running on OS X version 10.4.10, IDLE version 1.2.1, MacBook
>
We haven't had too many posts from people using IDLE on OSX, so it's
good to get some feedback :)

> Wish list:
> ---------------------
>
> Adjustable font/font size in dialog box entry fields.  Tracking the
> base editor font would be just as good.

Using the editor font size sounds good, but I don't think we should
use its font face. Perhaps we should use its font size for all of the
text in the dialogs, not just the entry boxes. (IMO making them
configurable is out of the question.)

> Adjustable width of scrolling key list in key preferences.
> Autosizing would be better.

I agree that it is currently too narrow. I suggest reorganizing the
window, having two frames one on top of the other instead of
side-by-side. The top one would allow managing key sets, the bottom
one would contain the list of key bindings. This would the list of key
bindings to be wider.

> An settable option to automatically call "Debug:Go to File/Line" when
> the shell gets an error would be nice, if feasible.

Hmm, that could be useful, though sometimes annoying. I don't think
IDLE should do too much automatic jumping around, that tends to be
very confusing. With a keyboard shortcut, would you still want this to
be automatic (save one keystroke)?

> A key on the "Debug:Go to File/Line" menu item to do the same would
> be nice too.

I agree. Any suggestions?

> Underlying operations to support keys for Kill/Yank on a line basis
> (i.e. without previous selection)  (I know, these are just hard-wired
> in my fingers from Emacs.  I haven't used Emacs in years, but I've
> been using editors that support Emacs-like keys)

I would also like this very much. (Ctrl-k already kills a line, but it
is simply deleted, you can't retrieve it.)

> Underlying operations for using key selection, i.e. Set Mark,
> selection is between
> Mark and Cursor.

I never really understand this request - is holding the Shift key down
really so hard?

I'm wary of such a feature because new users may trigger it by
accident. Not knowing how to end it, they would have text selected and
replaced all of the time, forcing them to close and reopen the window.

> Maybe not IDLE controllable, but it would be nice if the scroll-bars
> supported mouse roller-button scrolling on OS X

They don't? Using a roller on WinXP works fine, as well as holding the
middle mouse button and moving the mouse up/down. Sounds like a
platform specific bug. Can another OSX user confirm this?

> When keys are configurable, it's always nice if there's a way to type
> a key-combination and see the text you should enter to use that
> combination in the configuration.

That would be very nice, especially for novice users. It shouldn't
really be difficult to do with Tk. Someone just needs to make such a
dialog. I'm doing a lot of stuff and this isn't very high priority
IMHO, so I don't know if or when I'll get around to it.

> (+1 to existing suggestion for tabbed windows. Tear off tabs would be
> very, very
> nice, but that's asking a lot :) )

I'm working on it, but it could take a while. (don't hold your breath
for tear-offs though...)

> Bugs, maybe:
> ------------
>
> On a syntax error, the shell window is left over the source window
> obscuring the error highlighting.  The source window should pop to
> the top. (Or I don't see the reason for the behavior)

Do you mean when you use "Goto file/line"? If so, on WinXP it raises
the source window, so perhaps this is another platform specific bug.

> The menu item (Format:Format Paragraph) and the key preferences show
> this attached to Option-q.  When I do this the paragraph is formatted
> but an œ (oe ligature) is appended.  (In a common OS X text window,
> option shift inserts the ligature.) Control-Option-Shift just does
> the paragraph format.

This is a bug - nice catch! Need to add "return 'break'" at the end of
FormatParagraph.format_paragraph_event. I'll post a patch tomorrow
morning.

> Replace highlighting of finds after the first one occasionally fails
> to highlight.
>
> This is a useless report (I can't reproduce it,) but I had one
> incident of a run-away shell.  I accidently pasted a dictionary
> "{ <blah>:<blah>,... }" into the shell, typed something random in an
> attempt to clear it, went back to an edit window.  Response was slow
> and the fan came on louder than I've ever heard it. Both processors
> were at 100% and I couldn't close IDLE windows or quit IDLE.  I could
> edit in a window.  Force quit of IDLE worked.

That is weird. The only thing I know of that may be related is that
pasting large amounts of text into a window can cause similar effects,
i.e. slowdown and high CPU usage. This is one of the things the
Squeezer extension (found on PyPI) helps avoid.

> Jonathan

Thank you very much for this! It really helps us make IDLE better.

- Tal