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

[Jonathan Cronin]

On Nov 1, 2007, at 8:10 PM, Tal Einat wrote:
>
>> 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.)

Size is probably good enough; in my experience, when you can't change  
size a font change alone may help, but size change trumps font change  
for better legibility.

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

Sounds good.

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

No, a keystroke is pretty much as good.  Better, now that I think of
it; I want to read the error message before I jump.

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

Alt-e (for error?)
Alt-j (for jump to error line, a modified form of command-j)
Shift-Command-j (as above)
or
Command-j (i.e. in the shell window, jump to error line, in source  
window, get dialog to jump to line)

The last assumes no-one really uses Command-J in a shell window.  And  
that it's easy to do different things off the same key-sequence.  The  
key customize dialog doesn't distinguish shell and source windows, so  
that would also be a problem.

(I don't suggest function keys for two reasons. On Mac laptop  
keyboards, the function keys are overloaded with hardware functions  
(volume, screen brightness, embedded numeric pad shift and display  
swap) so require an extra shift key.  And I can't remember them, they  
have no mnemonic quality.)
>
>> 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?

Probably not, but I didn't know about it :) I'll try it now...
Yes, that's handy enough. It doesn't work for all the navigation key  
sequences: e.g. ^A, ^E, (which I take to be TCL defaults) but it's  
certainly 90% of the way. This isn't in the menu help.  Is it well- 
known from other editors?

(I also just discovered control-downarrow/uparrow, move by paragraph,
also useful, also not in the menu help.)

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

Having it as operation assignable to a key, but by default unassigned  
would take care of that.  (What you describe has happened to me in  
some vi-like editor on a customer host, so I certainly understand.)
>
>> 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.

I'll attempt one, i.e. a separate app(let) that just pops a dialog  
box, (I'll learn some tkinter etc.) but I can't commit to how soon.  
Pointers to where it would hook in? I've poked around briefly in the  
IDLE sources (I really wanted Kill/Yank :)) but was scared off, given  
the time I could reasonably now commit.

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

I mean when I select the Check Module menu item.  (Goto file/line  
works fine.) I assume the shell is used for the checking, but since  
the error is reported in a dialog window and highlighted in the  
source window, the shell window is irrelevant.

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


A pleasure.  I've just done my first serious work in Python/IDLE, a  
small dot pre-processor for software modeling diagrams and I am very  
enthused.

It should be called Pytho; it has the positive qualities of Play-Do  
and Lego: you get ideas squishing it through your fingers and it  
snaps together nicely to build things.

Jonathan