[Idle-dev] IDLE improvements

[Kurt B. Kaiser]

"Jason Doucette" <jason at jasondoucette.com> writes:

> Ok, great.  Are UI issues are considered bugs?  I believe so, as
> Franz Steinhäusler mentioned that Shift+Tab does not dedent as
> expected.  I have found many similar bugs -- some of them I believe
> to be more important than broken functionality bugs, since they are
> that disruptive to usability / productivity.

That would be a Request for Enhancement (RFE).

If an existing feature isn't working, that's a bug.  Adding or
enhancing a feature is an RFE, even if it's 'expected'.

There is already an RFE open for this request:

http://sourceforge.net/tracker/index.php?func=detail&aid=694339&group_id=5470&atid=355470

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.

>> This list is appropriate for general discussion of issues related to
>> IDLE development.
>>
>> The order of IDLE development priority is:
>>
>> 0. critical bugs
>> 1. patches for bugs
>> 2. important bugs submitted w/o patches.
>> 3. patches for new functionality
>>
>> Then requests for enhancement (RFE, use Sourceforge), 'normal' bugs
>> without patches, and the developer's personal interests are worked on
>> in some random fashion.
>>
>> Please review the archives to get a feel for IDLE's design goals:
>>
>> * Stability is more important than features.
>>
>> * Keep the surprise factor low.
>>
>> * Simple interface: usable by children as well as professionals.
>>
>> * (But satisfy 98% of professional needs for writing pure Python code)
>
> The above two points would 'OK' the request to submit broken UI
> functionality.  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.

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

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.

-- 
KBK