From kbk at shore.net  Sun Oct  2 05:41:50 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sat, 01 Oct 2005 23:41:50 -0400
Subject: [Idle-dev] IDLE development [moved from python-dev]
References: <b348a085050910165468abeb89@mail.gmail.com>
Message-ID: <8764sgio01.fsf@hydra.bayview.thirdcreek.com>

Noam Raphael <noamraph at gmail.com> writes: (on python-dev)

> More than a year and a half ago, I posted a big patch to IDLE which
> adds support for completion and much better calltips, along with some
> other improvements. Since then, I had some mail conversations with
> Kurt B. Kaiser, who is responsible for IDLE, which resulted in
> nothing. 

It resulted in my requesting some changes to what I felt was becoming
a very noisy interface.  You incorporated those changes 10Jul05.

> My last mail, from Jul 10, saying (with more details) "I made
> the minor changes you asked for, let's get it in, it's not very
> complicated" was unanswered.

Considered as a whole, the patch is a significant (and welcome)
addition to IDLE.  In fact, I need to ask you to send a contributor
agreement:

http://www.python.org/psf/contrib-form-python.html

Please note that there are two places on the form for you to sign so
that your previous Code Context patch will be covered.

The form address contains an error.  Please send the form to

Python Software Foundation
P. O. Box 653
Ipswich, MA 01938

Instructions for the form are at

http://www.python.org/psf/contrib.html

While I'm waiting for your form, I'll go ahead and incorporate the
patch on my system.  I may have additional comments :-)


In the future, please post on idle-dev or at least copy idle-dev.  I
sometimes go several weeks between scans of python-dev, which is why I
didn't see your post and the subsequent thread.

=================================>

> On 9/11/05, Guido van Rossum <guido at python.org> wrote:
>> On 9/10/05, Noam Raphael <noamraph at gmail.com> wrote:
>> > I and my colleges use IDLE intensively - that is, a heavily patched
>> > IDLE. It includes my patch and many other improvements made by me and
>> > my friends.
>> >
>> > The improved IDLE is MUCH better than the standard IDLE, especially
>> > for interactive work.
>> 
>> Could it be that this is a rather subjective judgement? It wouldn't be
>> the first time that someone pushing for their personal set of
>> functionality changes is overlooking the needs of other user groups.
>> 
> I don't think so, since:
> 1. These are added features, not functionality changes.
> 2. There are quite a lot of people using the improved IDLE where I
> work, and I never heard anyone saying he prefers the standard IDLE -
> on the contrary, many are asking how they can use the improved IDLE in
> their homes.
> 3. Kurt agreed to integrate the change - he just didn't do it.
>
>> > Since we would like to share our work with the
>> > rest of the world, if nothing is changed we would start a new IDLE
>> > fork soon, perhaps at python-hosting.com.
>> 
>> I have no problem with this. You might be able to save yourself some
>> maintenance work by structuring your version as a set of subclasses
>> rather than a set of patches (even if you distribute it as a complete
>> working program). Many people have needs that aren't met by standard
>> Python; they write their own modules or extensions and distribute
>> these independently from Python; your case probably isn't all that
>> different.
>> 
> I think that rewriting the patches as subclasses will be a lot of
> work, and won't be a very good idea - if you change one line in a
> function, copy-pasting it to a subclass and changing the line seems a
> little weird for me - not to mention the cases where some refactoring
> needs to be done. I think we will be talking about a separate package
> - say, idleforklib instead of idlelib. You can always run diff to find
> the differences between the two packages.
>
>> Often the needs of certain user groups and the development speeds of
>> such 3rd party modules are so different that it simply doesn't make
>> sense to fold them in the Python distribution anyway -- consider what
>> you would have to do if Kurt accepted your patches: you'll still have
>> to wait until Python 2.5 is released before others can benefit from
>> your changes, and if you come up with an improvement after that
>> release, your next chance will be 18 months later...
>> 
> I don't think so - if IDLE is developed on the Python CVS, we can
> still distribute a stand-alone package with IDLE from the CVS head,
> for eager people. 



A reasonable suggestion.  I thought of using IDLEfork, but I don't
want to encourage people to use the IDLEfork Tracker.  They should
use the Python Tracker for IDLE Patches/Bugs/RFE.  So we would need
to find another location that doesn't have a bug reporting mechanism.

For those who like to be on the bleeding edge, it's easy to replace
your .../Lib/idlelib with the CVS version without building all of
Python or even synching your CVS checkout to anything except idlelib.
If anyone would like instructions on how to do that, please ask.


> All others will get the changes a year later, which isn't that
> bad. Perhaps it can even be less than a year - since IDLE is a GUI
> application and not a library, so there isn't a lot of backward
> compatibility to maintain, it seems to me that updated versions can
> be shipped also with new minor versions of Python.


Those maintenance releases are intended to be of increasing stability,
with changes limited to bug fixes.


> The advantages of developing IDLE on the Python CVS are that there
> is no need to synchronize two versions, and a wider audience.  Of
> course, after you see the improved IDLE you will surely decide to
> immediately import it into the Python CVS, so there's not much of a
> problem... :)

:-)

-- 
KBK

From franz.steinhaeusler at gmx.at  Wed Oct  5 11:42:54 2005
From: franz.steinhaeusler at gmx.at (Franz Steinhäusler)
Date: Wed, 05 Oct 2005 11:42:54 +0200
Subject: [Idle-dev] Key Configuration bug
Message-ID: <pt77k1dtenerkuhtg2dl1kkhalgpq0bl9i@4ax.com>

Hello, I copied my post from comp.lang.python over here:

>Hi.
>
>I use Idle 1.1.1 on Python 2.4.1.
>
>The "Ctrl-[" and "Ctrl-]" key bindings for indenting do not work on
>non-us keyboards where brackets are accessed by the "Alt Gr" key.
>
>The Tab key seem to work for indenting a selected textblock on my
>swedish keyboard, but Shift-tab does not dedent as you would have
>expected.
>
>If I try to redefine key bindings in "options->Configure IDLE->Keys" so
>that Shift-Tab is bound to dedent, things seem to get really weird.
>
>After creating a "Custom key set"
>- the "Ok"-button does not close the options window, I have to use
>"Cancel" to get out.
>

I'v seen this also:
this must be a bug.


Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python24\lib\lib-tk\Tkinter.py", line 1345, in __call__
    return self.func(*args)
  File "C:\Python24\lib\idlelib\configDialog.py", line 1197, in Apply
    self.ActivateConfigChanges()
  File "C:\Python24\lib\idlelib\configDialog.py", line 1185, in
ActivateConfigCh
anges
    instance.ResetKeybindings()
  File "C:\Python24\lib\idlelib\EditorWindow.py", line 585, in
ResetKeybindings
    self.apply_bindings()
  File "C:\Python24\lib\idlelib\EditorWindow.py", line 837, in
apply_bindings
    text.event_add(event, *keylist)
  File "C:\Python24\lib\lib-tk\Tkinter.py", line 1299, in event_add
    self.tk.call(args)
TclError: bad event type or keysym "tab"
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python24\lib\lib-tk\Tkinter.py", line 1345, in __call__
    return self.func(*args)
  File "C:\Python24\lib\idlelib\configDialog.py", line 1192, in Ok
    self.Apply()
  File "C:\Python24\lib\idlelib\configDialog.py", line 1197, in Apply
    self.ActivateConfigChanges()
  File "C:\Python24\lib\idlelib\configDialog.py", line 1185, in
ActivateConfigCh
anges
    instance.ResetKeybindings()
  File "C:\Python24\lib\idlelib\EditorWindow.py", line 585, in
ResetKeybindings
    self.apply_bindings()
  File "C:\Python24\lib\idlelib\EditorWindow.py", line 837, in
apply_bindings
    text.event_add(event, *keylist)
  File "C:\Python24\lib\lib-tk\Tkinter.py", line 1299, in event_add
    self.tk.call(args)
TclError: bad event type or keysym "tab"


next time, I start:

C:\Python24\Lib\idlelib>idle.py
error reading package index file C:/Python24/tcl/tix8.1/pkgIndex.tcl:
invalid co
mmand name "lt}]}"
Traceback (most recent call last):
  File "C:\Python24\Lib\idlelib\idle.py", line 21, in ?
    idlelib.PyShell.main()
  File "C:\Python24\lib\idlelib\PyShell.py", line 1355, in main
    if not flist.open_shell():
  File "C:\Python24\lib\idlelib\PyShell.py", line 275, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Python24\lib\idlelib\PyShell.py", line 793, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "C:\Python24\lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python24\lib\idlelib\EditorWindow.py", line 108, in __init__
    self.apply_bindings()
  File "C:\Python24\lib\idlelib\EditorWindow.py", line 837, in
apply_bindings
    text.event_add(event, *keylist)
  File "C:\Python24\lib\lib-tk\Tkinter.py", line 1299, in event_add
    self.tk.call(args)
_tkinter.TclError: bad event type or keysym "tab"

(On Windows)
I discovered, looking in C:\.idlerc\config-keys.cfg

there was the entry
dedent-region = <Shift-Key-tab>

with an editor you can change it to uppercase:

dedent-region = <Shift-Key-Tab>

then it works again.

--
Franz Steinhaeusler


From kbk at shore.net  Mon Oct 10 06:01:24 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 10 Oct 2005 00:01:24 -0400
Subject: [Idle-dev] Tool Tips and Attribute Selector
Message-ID: <87vf066mwb.fsf@hydra.bayview.thirdcreek.com>

I've checked in Noam Raphael's idlesyntax.10Jul05.diff on a branch:

IDLE-syntax-branch.

To switch to this branch:
cvs up -r IDLE-syntax-branch

To switch back to the IDLE trunk:
cvs up -A

Further changes to this line of development should be submitted as
diffs against the new branch.

See Python Patch [ 906702 ] Syntax-related improvements to IDLE
for details.  

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

-- 
KBK

From franz.steinhaeusler at gmx.at  Mon Oct 10 11:30:17 2005
From: franz.steinhaeusler at gmx.at (Franz Steinhäusler)
Date: Mon, 10 Oct 2005 11:30:17 +0200
Subject: [Idle-dev] Tool Tips and Attribute Selector
References: <87vf066mwb.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <kvckk1tf60tl98i8u3hv8k6q8m1223i9bf@4ax.com>

On Mon, 10 Oct 2005 00:01:24 -0400, kbk at shore.net (Kurt B. Kaiser) wrote:

>I've checked in Noam Raphael's idlesyntax.10Jul05.diff on a branch:
>
>IDLE-syntax-branch.
>
>To switch to this branch:
>cvs up -r IDLE-syntax-branch
>
>To switch back to the IDLE trunk:
>cvs up -A
>
>Further changes to this line of development should be submitted as
>diffs against the new branch.
>
>See Python Patch [ 906702 ] Syntax-related improvements to IDLE
>for details.  
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=906702&group_id=5470&atid=305470


Hello Kurt, 

I'm very interested in those changes, but I don't have a cvs.
I tried to merge the idlesyntax.10Jul05.diff into the current 
idlelib dir; but there are some problems.

So my question:

Would it be possible to download the whole idlelib
directory as zip or as 7zip file?
--
Franz Steinhaeusler


From dooms at info.ucl.ac.be  Mon Oct 10 11:40:54 2005
From: dooms at info.ucl.ac.be (=?ISO-8859-1?Q?Gr=E9goire_Dooms?=)
Date: Mon, 10 Oct 2005 11:40:54 +0200
Subject: [Idle-dev] Tool Tips and Attribute Selector
In-Reply-To: <kvckk1tf60tl98i8u3hv8k6q8m1223i9bf@4ax.com>
References: <87vf066mwb.fsf@hydra.bayview.thirdcreek.com>
	<kvckk1tf60tl98i8u3hv8k6q8m1223i9bf@4ax.com>
Message-ID: <434A3726.7030401@info.ucl.ac.be>

Franz Steinh?usler wrote:

<snip>

>So my question:
>
>Would it be possible to download the whole idlelib
>directory as zip or as 7zip file?
>  
>

I have been providing patched files at 
http://www.info.ucl.ac.be/~dooms/python/IDLE_patch.zip for nearly two years.
Note these files are quite old but I have been using them in classroom 
whitout problems with a recent python2.3.
I think they might work as well with python2.4  alltough I didn't test that.
--
Gr?goire Dooms



From franz.steinhaeusler at gmx.at  Mon Oct 10 12:00:55 2005
From: franz.steinhaeusler at gmx.at (Franz Steinhäusler)
Date: Mon, 10 Oct 2005 12:00:55 +0200
Subject: [Idle-dev] Tool Tips and Attribute Selector
References: <87vf066mwb.fsf@hydra.bayview.thirdcreek.com>
	<kvckk1tf60tl98i8u3hv8k6q8m1223i9bf@4ax.com>
	<434A3726.7030401@info.ucl.ac.be>
Message-ID: <8tekk1df9le163h4ol715jifdlc2iq491r@4ax.com>

On Mon, 10 Oct 2005 11:40:54 +0200, Gr?goire Dooms <dooms at info.ucl.ac.be> wrote:

>Franz Steinh?usler wrote:
>
><snip>
>
>>So my question:
>>
>>Would it be possible to download the whole idlelib
>>directory as zip or as 7zip file?
>>  
>>
>
>I have been providing patched files at 
>http://www.info.ucl.ac.be/~dooms/python/IDLE_patch.zip for nearly two years.
>Note these files are quite old but I have been using them in classroom 
>whitout problems with a recent python2.3.
>I think they might work as well with python2.4  alltough I didn't test that.

Hello  Gr?goire,

thank you very much!
--
Franz Steinhaeusler


From jason at jasondoucette.com  Mon Oct 10 17:16:05 2005
From: jason at jasondoucette.com (Jason Doucette)
Date: Mon, 10 Oct 2005 12:16:05 -0300
Subject: [Idle-dev] IDLE improvements
Message-ID: <000a01c5cdad$898072a0$3500a8c0@OptimusPrime>

Hello,

I have been using IDLE within Windows XP for a little while now.  I have
analyzed quite a few problems, most of them caused by user interface issues.

What is the best method for me to make these issues known, so they can
possibly be fixed?  IDLE's main page states: "If you want to contribute to
IDLE, please join the IDLE-dev mailing list for IDLE developers. This is
where we set priorities and hash out designs."  So, this looks like this is
a good place to start.  Should I post concerns, one at a time, to this
mailing list?

Thanks,

-- 
Jason Doucette / Xona.com
www.jasondoucette.com / www.xona.com


From kbk at shore.net  Mon Oct 10 21:37:09 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 10 Oct 2005 15:37:09 -0400
Subject: [Idle-dev] IDLE improvements
In-Reply-To: <000a01c5cdad$898072a0$3500a8c0@OptimusPrime> (Jason Doucette's
	message of "Mon, 10 Oct 2005 12:16:05 -0300")
References: <000a01c5cdad$898072a0$3500a8c0@OptimusPrime>
Message-ID: <87achh6u56.fsf@hydra.bayview.thirdcreek.com>

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

> I have been using IDLE within Windows XP for a little while now.  I
> have analyzed quite a few problems, most of them caused by user
> interface issues.
>
> What is the best method for me to make these issues known, so they
> can possibly be fixed?  IDLE's main page states: "If you want to
> contribute to IDLE, please join the IDLE-dev mailing list for IDLE
> developers. This is where we set priorities and hash out designs."
> So, this looks like this is a good place to start.  Should I post
> concerns, one at a time, to this mailing list?

If you have identified actual bugs, please post them to the
Sourceforge Python Bug Tracker.  If you have patches, post to the
Python Patch Tracker.  Set the Category to IDLE.

http://sourceforge.net/projects/python/

That way they will not get lost, and there is a relatively orderly
process to respond to them.

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)

* Enhancement via IDLE's extension mechanism.

* Avoid creeping features.


Also, please don't feel, as some apparently do, that you should get
an answer for every comment you make, or feel badly when you don't.
Lack of response doesn't imply a lack of interest in your remarks,
just a shortage of time to discuss all of them.  We're all volunteers.

The truism is, "The more you yack, the less you hack."

Anyway, welcome to the list!

-- 
KBK

From kbk at shore.net  Mon Oct 10 21:56:31 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 10 Oct 2005 15:56:31 -0400
Subject: [Idle-dev] Tool Tips and Attribute Selector
In-Reply-To: <kvckk1tf60tl98i8u3hv8k6q8m1223i9bf@4ax.com> (Franz
	=?iso-8859-1?Q?Steinh=E4usler's?= message of "Mon, 10 Oct 2005 11:30:17
	+0200")
References: <87vf066mwb.fsf@hydra.bayview.thirdcreek.com>
	<kvckk1tf60tl98i8u3hv8k6q8m1223i9bf@4ax.com>
Message-ID: <8764s56t8w.fsf@hydra.bayview.thirdcreek.com>

Franz Steinh?usler <franz.steinhaeusler at gmx.at> writes:

> I'm very interested in those changes, but I don't have a cvs.
> I tried to merge the idlesyntax.10Jul05.diff into the current 
> idlelib dir; but there are some problems.

It merges cleanly into the current CVS.  By 'current', do you mean
some version of 2.4?

> So my question:
>
> Would it be possible to download the whole idlelib
> directory as zip or as 7zip file?

For this to be workable, IDLE development would have to be restricted
to the Python 2.4 feature set (or whatever is the current release).

I don't have any problem with that (so far as I know) but since I test
with Python 2.5 I might miss something.  Let me know if that's the
case and I'll try to fix it.

The easiest thing is for you to synch to idlelib.  I assume you are
running Windows; try TortiseCVS.  It's integrated with the Windows
file explorer and works like a charm.  It's faster than downloading
and executing an installer.

-- 
KBK

From franz.steinhaeusler at gmx.at  Tue Oct 11 15:58:20 2005
From: franz.steinhaeusler at gmx.at (Franz Steinhäusler)
Date: Tue, 11 Oct 2005 15:58:20 +0200
Subject: [Idle-dev] Tool Tips and Attribute Selector
References: <87vf066mwb.fsf@hydra.bayview.thirdcreek.com>
	<kvckk1tf60tl98i8u3hv8k6q8m1223i9bf@4ax.com>
	<8764s56t8w.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <39gnk11ogr1hoemb2iilugb8bjurvos25h@4ax.com>

On Mon, 10 Oct 2005 15:56:31 -0400, kbk at shore.net (Kurt B. Kaiser) wrote:

>Franz Steinh?usler <franz.steinhaeusler at gmx.at> writes:
>
>> I'm very interested in those changes, but I don't have a cvs.
>> I tried to merge the idlesyntax.10Jul05.diff into the current 
>> idlelib dir; but there are some problems.
>
>It merges cleanly into the current CVS.  By 'current', do you mean
>some version of 2.4?
>

Thank you for your answer,

Yes; Because cvs didn't work, I tried with patch.exe (gnuwin) to merge
this file, but maybe I made an error.
I tried somehow: patch idle.py idlesyntax.10Jul05.diff; some file
were updated, some not and at the end of the output of the console,
there was an error message; cannot remember exactly what.

>> So my question:
>>
>> Would it be possible to download the whole idlelib
>> directory as zip or as 7zip file?
>
>For this to be workable, IDLE development would have to be restricted
>to the Python 2.4 feature set (or whatever is the current release).
>
>I don't have any problem with that (so far as I know) but since I test
>with Python 2.5 I might miss something.  Let me know if that's the
>case and I'll try to fix it.
>
>The easiest thing is for you to synch to idlelib.  I assume you are
>running Windows; try TortiseCVS.  It's integrated with the Windows
>file explorer and works like a charm.  It's faster than downloading
>and executing an installer.

I think, it is the firewall, who blocks this:
Maybe the module or the protocol isn't ok

In C:\Python24\Lib\idlelib: "C:\Programme\TortoiseCVS\cvs.exe" "checkout" "-P" "idlelib"
CVSROOT=:pserver:anonymous at cvs.sourceforge.net:/cvsroot/python

cvs.exe [checkout aborted]: connect to cvs.sourceforge.net:2401 failed: 
Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht ordnungsgem?? reagiert hat, 
	oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat. 

Error, CVS operation failed

PS: the background is:
I want to enhance the wxPython shell pycrust and 
look or use something from idle code ... ;)

I know, there is the old problem of reinventing the wheel,
but I don't like tkinter, and pycrust has a few nice features
additionally (the graphical namespace viewer for example, display of locals and 
the possibility to integrate it into other programs like spe or pythoncard).

Cheers,



--
Franz Steinhaeusler


From jason at jasondoucette.com  Tue Oct 11 21:48:38 2005
From: jason at jasondoucette.com (Jason Doucette)
Date: Tue, 11 Oct 2005 16:48:38 -0300
Subject: [Idle-dev] IDLE improvements
References: <000a01c5cdad$898072a0$3500a8c0@OptimusPrime>
	<87achh6u56.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <007701c5ce9c$c75c9280$3500a8c0@OptimusPrime>

Kurt,

Thanks for your prompt reply.


> If you have identified actual bugs, please post them to the
> Sourceforge Python Bug Tracker.  If you have patches, post to the
> Python Patch Tracker.  Set the Category to IDLE.
>
> http://sourceforge.net/projects/python/
>
> That way they will not get lost, and there is a relatively orderly
> process to respond to them.

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.


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

Do I submit the bugs directly to the bug tracking database, or should I 
discuss them here first?


> * Enhancement via IDLE's extension mechanism.
>
> * Avoid creeping features.
>
>
> Also, please don't feel, as some apparently do, that you should get
> an answer for every comment you make, or feel badly when you don't.
> Lack of response doesn't imply a lack of interest in your remarks,
> just a shortage of time to discuss all of them.  We're all volunteers.
>
> The truism is, "The more you yack, the less you hack."
>
> Anyway, welcome to the list!

Thank you very much!  I appreciate the time you've taken to be very explicit 
in your response.

Take care,

-- 
Jason Doucette / Xona.com
www.jasondoucette.com / www.xona.com


From kbk at shore.net  Wed Oct 12 05:13:38 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Tue, 11 Oct 2005 23:13:38 -0400
Subject: [Idle-dev] IDLE improvements
In-Reply-To: <007701c5ce9c$c75c9280$3500a8c0@OptimusPrime> (Jason Doucette's
	message of "Tue, 11 Oct 2005 16:48:38 -0300")
References: <000a01c5cdad$898072a0$3500a8c0@OptimusPrime>
	<87achh6u56.fsf@hydra.bayview.thirdcreek.com>
	<007701c5ce9c$c75c9280$3500a8c0@OptimusPrime>
Message-ID: <878xwz4ecd.fsf@hydra.bayview.thirdcreek.com>

"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

From franz.steinhaeusler at gmx.at  Thu Oct 13 16:22:22 2005
From: franz.steinhaeusler at gmx.at (Franz Steinhäusler)
Date: Thu, 13 Oct 2005 16:22:22 +0200
Subject: [Idle-dev] Location of configuration files
Message-ID: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com>

Hello,

wouldn't it be better to place (on windows) not directly
into the root directory (I hate cluttering the root directory
with such "unnecessary" dirs ;) )

I would evaluate the environment variable APPDATA,
as most programs do.
If this does not exist (win98), then look for HOMEDIR;

only then, if HOMEDIR also not exist, use the root C:\.idle?

Any opinions?

--
Franz Steinhaeusler


From noamraph at gmail.com  Thu Oct 13 21:30:33 2005
From: noamraph at gmail.com (Noam Raphael)
Date: Thu, 13 Oct 2005 21:30:33 +0200
Subject: [Idle-dev] Missing MultiCall.py on syntax branch
Message-ID: <b348a0850510131230t6d7510fdp61727346e4a5973a@mail.gmail.com>

Hello,

I tried to update my cvs to the syntax branch, but IDLE didn't work
because the file MultiCall.py doesn't exist.

Is it on the CVS?

From noamraph at gmail.com  Thu Oct 13 21:36:14 2005
From: noamraph at gmail.com (Noam Raphael)
Date: Thu, 13 Oct 2005 21:36:14 +0200
Subject: [Idle-dev] Missing MultiCall.py on syntax branch
In-Reply-To: <b348a0850510131230t6d7510fdp61727346e4a5973a@mail.gmail.com>
References: <b348a0850510131230t6d7510fdp61727346e4a5973a@mail.gmail.com>
Message-ID: <b348a0850510131236k55be24f0na530bdaceae0cb2d@mail.gmail.com>

Well, the same with HyperParser.py, AutoComplete.py and AutoCompleteWindow.py.

On 10/13/05, Noam Raphael <noamraph at gmail.com> wrote:
> Hello,
>
> I tried to update my cvs to the syntax branch, but IDLE didn't work
> because the file MultiCall.py doesn't exist.
>
> Is it on the CVS?
>

From kbk at shore.net  Fri Oct 14 01:49:38 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 13 Oct 2005 19:49:38 -0400
Subject: [Idle-dev] Missing MultiCall.py on syntax branch
In-Reply-To: <b348a0850510131236k55be24f0na530bdaceae0cb2d@mail.gmail.com>
	(Noam Raphael's message of "Thu, 13 Oct 2005 21:36:14 +0200")
References: <b348a0850510131230t6d7510fdp61727346e4a5973a@mail.gmail.com>
	<b348a0850510131236k55be24f0na530bdaceae0cb2d@mail.gmail.com>
Message-ID: <87ek6pdlkd.fsf@hydra.bayview.thirdcreek.com>

Noam Raphael <noamraph at gmail.com> writes:

> Well, the same with HyperParser.py, AutoComplete.py and AutoCompleteWindow.py.
>
> On 10/13/05, Noam Raphael <noamraph at gmail.com> wrote:
>> Hello,
>>
>> I tried to update my cvs to the syntax branch, but IDLE didn't work
>> because the file MultiCall.py doesn't exist.
>>
>> Is it on the CVS?

Noam, I'm sorry! You're right, I forgot to cvs add them.  I just checked
them in.

-- 
KBK

From kbk at shore.net  Fri Oct 14 01:54:49 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 13 Oct 2005 19:54:49 -0400
Subject: [Idle-dev] Location of configuration files
In-Reply-To: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com> (Franz
	=?iso-8859-1?Q?Steinh=E4usler's?= message of "Thu, 13 Oct 2005 16:22:22
	+0200")
References: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com>
Message-ID: <87achddlbq.fsf@hydra.bayview.thirdcreek.com>

Franz Steinh?usler <franz.steinhaeusler at gmx.at> writes:

> wouldn't it be better to place (on windows) not directly
> into the root directory (I hate cluttering the root directory
> with such "unnecessary" dirs ;) )
>
> I would evaluate the environment variable APPDATA,
> as most programs do.
> If this does not exist (win98), then look for HOMEDIR;
>
> only then, if HOMEDIR also not exist, use the root C:\.idle?
>
> Any opinions?

I don't worry too much about W98, they are single user systems
and there isn't much clutter.  If you want to submit a patch,
I'll probably add it, so long as it doesn't break systems which
already have their .idlerc in c:\.

It's been like this forever on W98.  W2K and WXP put .idlerc into the
correct user directory.

-- 
KBK

From franz.steinhaeusler at gmx.at  Fri Oct 14 12:40:37 2005
From: franz.steinhaeusler at gmx.at (Franz Steinhäusler)
Date: Fri, 14 Oct 2005 12:40:37 +0200
Subject: [Idle-dev] Location of configuration files
References: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com>
	<87achddlbq.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <1j2vk1lo2fo1o9tmjbs7jou1k7adpdo6au@4ax.com>

On Thu, 13 Oct 2005 19:54:49 -0400, kbk at shore.net (Kurt B. Kaiser) wrote:

>Franz Steinh?usler <franz.steinhaeusler at gmx.at> writes:
>
>> wouldn't it be better to place (on windows) not directly
>> into the root directory (I hate cluttering the root directory
>> with such "unnecessary" dirs ;) )
>>
>> I would evaluate the environment variable APPDATA,
>> as most programs do.
>> If this does not exist (win98), then look for HOMEDIR;
>>
>> only then, if HOMEDIR also not exist, use the root C:\.idle?
>>
>> Any opinions?
>
>I don't worry too much about W98, they are single user systems
>and there isn't much clutter.  If you want to submit a patch,
>I'll probably add it, so long as it doesn't break systems which
>already have their .idlerc in c:\.
>
>It's been like this forever on W98.  W2K and WXP put .idlerc into the
>correct user directory.

Hello Kurt,

thank you for your answer.

Maybe it is better to leave it as it is;
people are used to it anyway.
--
Franz Steinhaeusler


From jason at jasondoucette.com  Fri Oct 14 21:26:30 2005
From: jason at jasondoucette.com (Jason Doucette)
Date: Fri, 14 Oct 2005 16:26:30 -0300
Subject: [Idle-dev] Location of configuration files
References: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com>
	<87achddlbq.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <006901c5d0f5$2f8a87e0$3500a8c0@OptimusPrime>

Hello,

> > wouldn't it be better to place (on windows) not directly
> > into the root directory (I hate cluttering the root directory
> > with such "unnecessary" dirs ;) )
> >
> > [snip]
> >
> > Any opinions?

Franz, I agree with the cluttering of the root directory.  I was surprised 
to find on my Windows XP box that it installed, by default, into C:\, rather 
than in C:\Program Files.

I realize the installer gave the option to install to an alternative 
location, but it is best to let installers do what they default to -- simply 
because this is most tested variant (for some software, it is the only 
variant that works).  Thus, you have to expect that most people will install 
to the default location, and the default location should make sense.

I noticed in the reported bugs: http://www.python.org/2.4.2/bugs.html
that had I chosen to install to C:\Program Files, it would have failed --  
so, certainly, it is smart to leave things 'as is'. :)

> I don't worry too much about W98, they are single user systems
> and there isn't much clutter.  If you want to submit a patch,
> I'll probably add it, so long as it doesn't break systems which
> already have their .idlerc in c:\.
>
> It's been like this forever on W98.  W2K and WXP put .idlerc into the
> correct user directory.

Kurt, I notice the .idlerc directory on my Windows XP box is located here:
C:\Documents and Settings\Jason\.idlerc

Shouldn't this be:
C:\Documents and Settings\Jason\Application Data\.idlerc

(I apologize if I am missing something for being 'out of the loop'.)

P.S.  I noticed that when Kurt replies, that he replies directly to the 
poster, and CC's it to the idle-dev mailing list.  Therefore, I will follow 
suit.  Is this proper?

-- 
Jason Doucette / Xona.com
www.jasondoucette.com / www.xona.com



From kbk at shore.net  Sat Oct 15 07:50:50 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sat, 15 Oct 2005 01:50:50 -0400
Subject: [Idle-dev] Location of configuration files
In-Reply-To: <006901c5d0f5$2f8a87e0$3500a8c0@OptimusPrime> (Jason Doucette's
	message of "Fri, 14 Oct 2005 16:26:30 -0300")
References: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com>
	<87achddlbq.fsf@hydra.bayview.thirdcreek.com>
	<006901c5d0f5$2f8a87e0$3500a8c0@OptimusPrime>
Message-ID: <87psq78h1h.fsf@hydra.bayview.thirdcreek.com>

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

>> > wouldn't it be better to place (on windows) not directly
>> > into the root directory (I hate cluttering the root directory
>> > with such "unnecessary" dirs ;) )
>> >
>> > [snip]
>> >
>> > Any opinions?
>
> Franz, I agree with the cluttering of the root directory.  I was
> surprised to find on my Windows XP box that it installed, by
> default, into C:\, rather than in C:\Program Files.
>
> I realize the installer gave the option to install to an alternative
> location, but it is best to let installers do what they default to
> -- simply because this is most tested variant (for some software, it
> is the only variant that works).  Thus, you have to expect that most
> people will install to the default location, and the default
> location should make sense.

GvR recommends that Python be installed at toplevel.  Especially when
using the command line, the space in "Program Files" causes problems.

You'll find that even Windows by itself sometimes has problems with
that space when you are running a command window; you need to quote
the silly thing.

> I noticed in the reported bugs:
> http://www.python.org/2.4.2/bugs.html that had I chosen to install
> to C:\Program Files, it would have failed -- so, certainly, it is
> smart to leave things 'as is'. :)

IDLE installs and works ok, it's the installer which is having
problems creating the shortcuts.  The instructions describe how to
manually fix the shortcuts.

>> I don't worry too much about W98, they are single user systems and
>> there isn't much clutter.  If you want to submit a patch, I'll
>> probably add it, so long as it doesn't break systems which already
>> have their .idlerc in c:\.
>>
>> It's been like this forever on W98.  W2K and WXP put .idlerc into
>> the correct user directory.
>
> Kurt, I notice the .idlerc directory on my Windows XP box is located here:
> C:\Documents and Settings\Jason\.idlerc
>
> Shouldn't this be:
> C:\Documents and Settings\Jason\Application Data\.idlerc
>
> (I apologize if I am missing something for being 'out of the loop'.)

Yes, that might be even better.  Send a patch?

> P.S.  I noticed that when Kurt replies, that he replies directly to the 
> poster, and CC's it to the idle-dev mailing list.  Therefore, I will follow 
> suit.  Is this proper?

Just to the list is best.

-- 
KBK

From jason at jasondoucette.com  Tue Oct 18 21:17:53 2005
From: jason at jasondoucette.com (Jason Doucette)
Date: Tue, 18 Oct 2005 16:17:53 -0300
Subject: [Idle-dev] Location of configuration files
References: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com><87achddlbq.fsf@hydra.bayview.thirdcreek.com><006901c5d0f5$2f8a87e0$3500a8c0@OptimusPrime>
	<87psq78h1h.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <000301c5d418$a4bb2940$3500a8c0@OptimusPrime>

Kurt,

> GvR recommends that Python be installed at toplevel.  Especially when
> using the command line, the space in "Program Files" causes problems.
>
> You'll find that even Windows by itself sometimes has problems with
> that space when you are running a command window; you need to quote
> the silly thing.

Yes, it's give and take...

I hope GvR understands this type of installation is not standard, and not 
what the user expects.  Doing something the user does not expect is an 
indication something is likely broken.

(e.g. This essay by Joel Spolsky shows a great example of him breaking his 
own design principle:
http://www.joelonsoftware.com/articles/UsabilityTestingwithMorae.html
"...The program design violated a principle I wrote myself in big bold print 
in my own book: it didn't do what you expected...")

Regarding all the 'bad' about the spaces in file/directory names, I am not 
sure how this differs much from other OS's.  The biggie is that "Program 
Files" is the default/expected install location for most software, so nearly 
all of it is put through the 'test', where it can be avoided on other OS's.

I believe an important issue is that developers should test their software 
under "Program Files", since this is the likely install location some 
customers will want -- as it is best to be bitten by the annoyance during 
development, than during that first install of a customer who does not like 
cluttering the root directory.  Installing Python into "Program Files" will 
help force this to occur.


>> Kurt, I notice the .idlerc directory on my Windows XP box is located 
>> here:
>> C:\Documents and Settings\Jason\.idlerc
>>
>> Shouldn't this be:
>> C:\Documents and Settings\Jason\Application Data\.idlerc
>>
>> (I apologize if I am missing something for being 'out of the loop'.)
>
> Yes, that might be even better.  Send a patch?

Ok, I have NO experience with creating / sending patches.  I will try and 
look into it if I have some time.  For now, should I post a bug within the 
bug database?


-- 
Jason Doucette / Xona.com
www.jasondoucette.com / www.xona.com


From kbk at shore.net  Thu Oct 20 00:01:04 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Wed, 19 Oct 2005 18:01:04 -0400
Subject: [Idle-dev] Location of configuration files
In-Reply-To: <000301c5d418$a4bb2940$3500a8c0@OptimusPrime> (Jason Doucette's
	message of "Tue, 18 Oct 2005 16:17:53 -0300")
References: <r7rsk1te17s8fnujqiovupo1fmnphb2tsn@4ax.com>
	<87achddlbq.fsf@hydra.bayview.thirdcreek.com>
	<006901c5d0f5$2f8a87e0$3500a8c0@OptimusPrime>
	<87psq78h1h.fsf@hydra.bayview.thirdcreek.com>
	<000301c5d418$a4bb2940$3500a8c0@OptimusPrime>
Message-ID: <871x2hyxnj.fsf@hydra.bayview.thirdcreek.com>

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

>>> Kurt, I notice the .idlerc directory on my Windows XP box is located 
>>> here:
>>> C:\Documents and Settings\Jason\.idlerc
>>>
>>> Shouldn't this be:
>>> C:\Documents and Settings\Jason\Application Data\.idlerc
>>>
>>> (I apologize if I am missing something for being 'out of the loop'.)
>>
>> Yes, that might be even better.  Send a patch?
>
> Ok, I have NO experience with creating / sending patches.  I will try and 
> look into it if I have some time.  For now, should I post a bug within the 
> bug database?

I'd rather have the patch.

-- 
KBK

From noamraph at gmail.com  Fri Oct 21 03:22:14 2005
From: noamraph at gmail.com (Noam Raphael)
Date: Fri, 21 Oct 2005 03:22:14 +0200
Subject: [Idle-dev] Fix freezes!
Message-ID: <b348a0850510201822g5e8025a9ib4bbae2ef28c8a08@mail.gmail.com>

A long time ago I opened IDLEfork bug 81789, which fixes two IDLE
freezes, when doing things simultaniously - one is when executing
something while a thread prints output, and the other is when
interrupting the subprocess in the middle of running IDLE code.

Here is the message sent to idle-dev on March '04.

Bugs item #817898, was opened at 2003-10-05 00:42
Message generated for change (Comment added) made by noamr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=817898&group_id=9579

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Threads and output

Initial Comment:
Hello,
If a thread writes output (into sys.stdin) while a
command should be executed, the command you tried to
execute never finishes executing, so you are stuck.
For example, type this:

>>> from threading import Thread
>>> def f():
	for i in range(200):
		print i,
>>> t = Thread(target=f)
>>> t.start()

Now, while the numbers are showing, type Enter. After
the numbers stopped showing, you&#039;ll notive that you
can&#039;t execute anything, until you restart the shell.

I noticed this because I wrote a function which
executes at a seperate thread and writes to sys.stderr.
If I try to execute something while the output is being
printed, I get stuck.

Bye,
Noam

----------------------------------------------------------------------

>Comment By: Noam Raphael (noamr)
Date: 2004-03-07 18:31

Message:
Logged In: YES
user_id=679426

First, another problem:
If you press Ctrl+C while an exception is being printed,
IDLE gets stuck.
You can test it easily using this:
>>> def f(n):
1/n
f(n-1)
>>> f(10)

And here's the solution.
The first problem (what I thought was threading) happens
because when the subprocess prints output, the write()
method of the Text is called, which calls its update()
method, which causes Tkinter to handle pending events,
including a request for execution. If this happens from a
poll_subprocess call, the current pollresponse() call may
receive the response for execution, and ignore it because it
was called before the execution started.

The second problem happens because the interrupt happens in
the exception handling part of Executive's runcode(), and
the main process doesn't know how to handle an exception
which runcode() didn't handle.

The solution for the first problem is to use the RPC's
'responses' dict. RPC puts a response in the dict if it
finds a Condition matching the sequence number in its
'cvars' dict, so the solution puts a dummy Condition in
cvars. This changes PyShell and RemoteDebugger, because they
use PyShell.active_seq.
Another change, to rpc.py, is that I added an optional
argument for pollresponse(), which makes it quit after a
certain period of time even if not all messages were handled
- there's no need to wait for all messages to be handled in
poll_subprocess.

The solution for the second problem is to add a global
variable to run.py, which states whether the subprocess
should consider interrupt requests. It should consider them
only when a user code is being executed.

(The patch is against the current IDLE cvs, patched with my
syntax improvements, but it works against unpatched IDLE
too. I didn't check it against IDLEfork)

Noam Raphael

From noamraph at gmail.com  Fri Oct 21 03:28:14 2005
From: noamraph at gmail.com (Noam Raphael)
Date: Fri, 21 Oct 2005 03:28:14 +0200
Subject: [Idle-dev] Unicode in the interactive interpreter
Message-ID: <b348a0850510201828v297eb0fdt6f157dc97feabc6d@mail.gmail.com>

Hello,

I now posted a patch. In case sourceforge forgets to send a mail, please look at
https://sourceforge.net/tracker/index.php?func=detail&aid=1333679&group_id=5470&atid=305470

It's about being able to type unicode chars in the interactive shell.

Noam

From s.joaopaulo at gmail.com  Fri Oct 21 08:48:58 2005
From: s.joaopaulo at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Paulo_Silva?=)
Date: Fri, 21 Oct 2005 06:48:58 +0000
Subject: [Idle-dev] A little improvement on identation
Message-ID: <787073ca0510202348u72ed6b69v@mail.gmail.com>

Hi all (first post here),

Last month I'd seen a introductory article about Python in a magazine.
At some part, the author said to be careful with identation, and wrote
that example (on interactive mode):

Do that:
>>> def foo():
             pass

Don't do:
>>> def foo():
  pass

Of course both methods are correct. I believe he was using IDLE. The
"pure text" interactive mode would use:

>>> def foo():
...         pass # Perhaps the font is not helping to see.

So, mainly for beginners (I believe for everyone), the IDLE
interactive mode could work like the "pure text" mode. The '...' is
very useful to maintain the identation, and the code becomes easier to
read and write.

--
Jo?o Paulo da Silva

(Sorry any english errors...)

From dooms at info.ucl.ac.be  Fri Oct 21 09:55:53 2005
From: dooms at info.ucl.ac.be (=?ISO-8859-1?Q?Gr=E9goire_Dooms?=)
Date: Fri, 21 Oct 2005 09:55:53 +0200
Subject: [Idle-dev] A little improvement on identation
In-Reply-To: <787073ca0510202348u72ed6b69v@mail.gmail.com>
References: <787073ca0510202348u72ed6b69v@mail.gmail.com>
Message-ID: <43589F09.1000006@info.ucl.ac.be>

Jo?o Paulo Silva wrote:


<snip>

>So, mainly for beginners (I believe for everyone), the IDLE
>interactive mode could work like the "pure text" mode. The '...' is
>very useful to maintain the identation, and the code becomes easier to
>read and write.
>
>  
>
There is a similar issue in the Python tutorial where the first examples 
use the Cpython interpreter style (ps2="...")
while latter examples use Idle style. The rationale is that using the 
Idle style eases copy-paste of the code.
--
Gr?goire Dooms



From noamraph at gmail.com  Fri Oct 21 14:11:16 2005
From: noamraph at gmail.com (Noam Raphael)
Date: Fri, 21 Oct 2005 14:11:16 +0200
Subject: [Idle-dev] A little improvement on identation
In-Reply-To: <43589F09.1000006@info.ucl.ac.be>
References: <787073ca0510202348u72ed6b69v@mail.gmail.com>
	<43589F09.1000006@info.ucl.ac.be>
Message-ID: <b348a0850510210511n62e62280ga14b34d0f37732cc@mail.gmail.com>

On 10/21/05, Gr?goire Dooms <dooms at info.ucl.ac.be> wrote:
> The rationale is that using the
> Idle style eases copy-paste of the code.

I think that this is one reason, but probably the main reason is that
in IDLE the complete block is editable, and those three dots would get
in the middle.

I think that it may actually be a good idea, but it would need some
work - for example, pressing backspace when the cursor is after the
"dot prompt" should delete the prompt and get to the previous line.

Interesting...
Noam

From ronmac at media.mit.edu  Fri Oct 21 22:36:42 2005
From: ronmac at media.mit.edu (Ron MacNeil)
Date: Fri, 21 Oct 2005 16:36:42 -0400
Subject: [Idle-dev] newbie question: getting emacs keybindings in IDLE
Message-ID: <4359515A.7040807@media.mit.edu>

I am using IDLE version 1.1.1 in python 2.4.1 and would like to add the
simplest emacs keybindings like C-p for 'move up one line', C-f 'move 
forward a character'... C-n  'move down a line'... etc....

Can you please point me to some approach that will do this? I've tried to edit the existing IDLE keybindings but didn't really get very 
far (kept banging into C-f being bound to Find even though I removed all references to it in config-keys.def.... etc )
I also have tried using XEmacs and find the lack of color a real pain.  I've searched the web for emacs keybindings for 
IDLE and found some interesting pointers but have not got anything to work..
any help will be much appreciated..
many thanks,
cheers, ronmac






From ronmac at media.mit.edu  Fri Oct 21 22:39:38 2005
From: ronmac at media.mit.edu (Ron MacNeil)
Date: Fri, 21 Oct 2005 16:39:38 -0400
Subject: [Idle-dev] newbie question: getting emacs keybindings in IDLE
In-Reply-To: <4359515A.7040807@media.mit.edu>
References: <4359515A.7040807@media.mit.edu>
Message-ID: <4359520A.3060906@media.mit.edu>

forgot to mention that I'm working on WinXP..
thanks,
cheers, ronmac

Ron MacNeil wrote:

> I am using IDLE version 1.1.1 in python 2.4.1 and would like to add the
> simplest emacs keybindings like C-p for 'move up one line', C-f 'move 
> forward a character'... C-n  'move down a line'... etc....
>
> Can you please point me to some approach that will do this? I've tried 
> to edit the existing IDLE keybindings but didn't really get very far 
> (kept banging into C-f being bound to Find even though I removed all 
> references to it in config-keys.def.... etc )
> I also have tried using XEmacs and find the lack of color a real 
> pain.  I've searched the web for emacs keybindings for IDLE and found 
> some interesting pointers but have not got anything to work..
> any help will be much appreciated..
> many thanks,
> cheers, ronmac
>
>
>
>
>


From kbk at shore.net  Fri Oct 21 23:48:11 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Fri, 21 Oct 2005 17:48:11 -0400
Subject: [Idle-dev] newbie question: getting emacs keybindings in IDLE
In-Reply-To: <4359515A.7040807@media.mit.edu> (Ron MacNeil's message of "Fri, 
	21 Oct 2005 16:36:42 -0400")
References: <4359515A.7040807@media.mit.edu>
Message-ID: <87d5lyv8x0.fsf@hydra.bayview.thirdcreek.com>

Ron MacNeil <ronmac at media.mit.edu> writes:

> I am using IDLE version 1.1.1 in python 2.4.1 and would like to add
> the simplest emacs keybindings like C-p for 'move up one line', C-f
> 'move forward a character'... C-n 'move down a line'... etc....
>
> Can you please point me to some approach that will do this? I've
> tried to edit the existing IDLE keybindings but didn't really get
> very far (kept banging into C-f being bound to Find even though I
> removed all references to it in config-keys.def.... etc ) I also
> have tried using XEmacs and find the lack of color a real pain.
> I've searched the web for emacs keybindings for IDLE and found some
> interesting pointers but have not got anything to work..

Simple cursor movement in IDLE is done via the tkinter/Tk library.
IDLE doesn't have virtual events that can be bound to <cursor-left>
and so forth.  So there isn't any simple way to do what you are asking.

I think most emacs users these days use the arrow keys, I certainly
do.  Control-f etc. were useful in the olden days when many keyboards
didn't have cursor keys.  Unlike the old Wordstar sexd cursor movement
keys, they aren't particularly convenient bindings.  I'm not going to
type a chord just to move a cursor, especially now that the Control
key is no longer where god intended it to be.

Note that Control-left and Control-right moves by words (in a peculiar,
but useful way).  Control-up and down move by blank-line separated
blocks.

The way to modify IDLE keybindings is to use the Options / Configure
IDLE / Keys dialog.  You "Save as a New Custom Key Set".  This creates
a config-keys.cfg file in your .idlerc directory.  You shouldn't
modify config-keys.def, that's intended to be "factory issue".

-- 
KBK

From ronmac at media.mit.edu  Sat Oct 22 02:06:17 2005
From: ronmac at media.mit.edu (Ron MacNeil)
Date: Fri, 21 Oct 2005 20:06:17 -0400
Subject: [Idle-dev] newbie question: getting emacs keybindings in IDLE
In-Reply-To: <87d5lyv8x0.fsf@hydra.bayview.thirdcreek.com>
References: <4359515A.7040807@media.mit.edu>
	<87d5lyv8x0.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <43598279.8020604@media.mit.edu>



Kurt B. Kaiser wrote:

>Ron MacNeil <ronmac at media.mit.edu> writes:
>
>  
>
>>I am using IDLE version 1.1.1 in python 2.4.1 and would like to add
>>the simplest emacs keybindings like C-p for 'move up one line', C-f
>>'move forward a character'... C-n 'move down a line'... etc....
>>
>>Can you please point me to some approach that will do this? I've
>>tried to edit the existing IDLE keybindings but didn't really get
>>very far (kept banging into C-f being bound to Find even though I
>>removed all references to it in config-keys.def.... etc ) I also
>>have tried using XEmacs and find the lack of color a real pain.
>>I've searched the web for emacs keybindings for IDLE and found some
>>interesting pointers but have not got anything to work..
>>    
>>
>
>Simple cursor movement in IDLE is done via the tkinter/Tk library.
>IDLE doesn't have virtual events that can be bound to <cursor-left>
>and so forth.  So there isn't any simple way to do what you are asking.
>  
>

is there any way to, even in a convoluted way, map "what the left arrow 
key does" or "move cursor left one space"  to C-b?

>I think most emacs users these days use the arrow keys, I certainly
>do.  Control-f etc. were useful in the olden days when many keyboards
>didn't have cursor keys.  Unlike the old Wordstar sexd cursor movement
>keys, they aren't particularly convenient bindings.  I'm not going to
>type a chord just to move a cursor, especially now that the Control
>key is no longer where god intended it to be.
>  
>
God would be happy typing on my keyboard... I used keyRemap to put the 
control key under my left thumb...
I've gotten very used to moving the cursor with those few commands when 
I'm working hard on just a local area of code..
moving my hand away to get to the arrow keys is just not quite it... 
anyway...

>Note that Control-left and Control-right moves by words (in a peculiar,
>but useful way).  Control-up and down move by blank-line separated
>blocks.
>  
>
>The way to modify IDLE keybindings is to use the Options / Configure
>IDLE / Keys dialog.  You "Save as a New Custom Key Set".  This creates
>a config-keys.cfg file in your .idlerc directory.  You shouldn't
>modify config-keys.def, that's intended to be "factory issue".
>  
>
right... I had saved the original config-key.def and now made custom 
config-keys.cfg...
thanks much...
cheers, ronmac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20051021/ce116680/attachment.htm

From kbk at shore.net  Sat Oct 22 18:23:13 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sat, 22 Oct 2005 12:23:13 -0400
Subject: [Idle-dev] newbie question: getting emacs keybindings in IDLE
In-Reply-To: <43598279.8020604@media.mit.edu> (Ron MacNeil's message of "Fri, 
	21 Oct 2005 20:06:17 -0400")
References: <4359515A.7040807@media.mit.edu>
	<87d5lyv8x0.fsf@hydra.bayview.thirdcreek.com>
	<43598279.8020604@media.mit.edu>
Message-ID: <87r7adttam.fsf@hydra.bayview.thirdcreek.com>

Ron MacNeil <ronmac at media.mit.edu> writes:

[KBK]
>>Simple cursor movement in IDLE is done via the tkinter/Tk library.
>>IDLE doesn't have virtual events that can be bound to <cursor-left>
>>and so forth.  So there isn't any simple way to do what you are asking.
>>
>>
>
> is there any way to, even in a convoluted way, map "what the left arrow 
> key does" or "move cursor left one space"  to C-b?

These bindings are intercepted by the Tk event loop and passed to the
Text widget in the IDLE Edit window.  You could investigate tkinter
and the Tk Text widget itself.  Note that there are a few bindings
(besides the cursor keys) passed through from Tk and available in
IDLE: C-a, C-e, C-k for example.  If you figure out how those bindings
work, you probably can solve your problem.  Let us know what you find
out.

http://www.tcl.tk/man/tcl8.4/TkCmd/contents.htm

Also, there is a mailing list, Tkinter-discuss at python.org, which might
be helpful.

-- 
KBK

From s.joaopaulo at gmail.com  Sat Oct 22 19:54:38 2005
From: s.joaopaulo at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Paulo_Silva?=)
Date: Sat, 22 Oct 2005 17:54:38 +0000
Subject: [Idle-dev] A little improvement on identation
In-Reply-To: <b348a0850510210511n62e62280ga14b34d0f37732cc@mail.gmail.com>
References: <787073ca0510202348u72ed6b69v@mail.gmail.com>
	<43589F09.1000006@info.ucl.ac.be>
	<b348a0850510210511n62e62280ga14b34d0f37732cc@mail.gmail.com>
Message-ID: <787073ca0510221054i3c928a3y@mail.gmail.com>

Yes, I haven't think on that.

It would be interesting turning the left three chars unselectable and
uneditable.

A possible implementation could use two frames in the main text area.

Well, I'll take a look at the source, and try to purpose something
more consistent.

--
Jo?o Paulo da Silva

2005/10/21, Noam Raphael <noamraph at gmail.com>:
> On 10/21/05, Gr?goire Dooms <dooms at info.ucl.ac.be> wrote:
> > The rationale is that using the
> > Idle style eases copy-paste of the code.
>
> I think that this is one reason, but probably the main reason is that
> in IDLE the complete block is editable, and those three dots would get
> in the middle.
>
> I think that it may actually be a good idea, but it would need some
> work - for example, pressing backspace when the cursor is after the
> "dot prompt" should delete the prompt and get to the previous line.
>
> Interesting...
> Noam
>

From jason at jasondoucette.com  Wed Oct 26 05:55:44 2005
From: jason at jasondoucette.com (Jason Doucette)
Date: Wed, 26 Oct 2005 00:55:44 -0300
Subject: [Idle-dev] IDLE improvements
References: <000a01c5cdad$898072a0$3500a8c0@OptimusPrime><87achh6u56.fsf@hydra.bayview.thirdcreek.com><007701c5ce9c$c75c9280$3500a8c0@OptimusPrime>
	<878xwz4ecd.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <000501c5d9e1$2fcbc6c0$3500a8c0@OptimusPrime>

Kurt,

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

Ok, I understand the logic: Let's add more features and make it more 
powerful, rather than sit and tweak each UI issue to perfection.  However, 
certain UI issues can be very *counter productive*, thus I would assume they 
hold more 'weight'.

A quick question:  Is IDLE Windows-only?


> There is already an RFE open for this request:
> http://sourceforge.net/tracker/index.php?func=detail&aid=694339&group_id=5470&atid=355470

Note: the above URL, while logged into sourceforge, does not allow me to add 
a comment.  If https:// is used, instead, it works.  I'm new to sourceforge, 
so I didn't know what was going on at first.  Just a heads up for future URL 
postings.


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

I certainly agree with Raymond.  I am not sure what you mean by "python mode 
= smart tab indent and backspace dedent", since I believe IDLE already does 
these things.  On that topic of smart indents, I notice areas IDLE could be 
smarter in, such as when "else:" or "elif xxx:" is typed, it could dedent 
automatically.


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

Regarding your comment "The experts will find the features", it sounds like 
you would likely disregard any UI improvements.  My thought is if IDLE 
worked as expected, according to standards set by other programs that most 
people are already used to, then learning Python with IDLE may be more 
comfortable to more users, and thus may attract more users.  Is the 
attraction of more users (i.e. popularity) a consideration?  If so, you may 
wish to hold UI in higher regards.


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

Ok.  I am sorry I took so long to respond, but here's a quick (?) list:

- The cursor blinks even during motion... by far, the #1 annoyance.  It 
severely slows down typing speed, since you have to wait to see where the 
cursor is after moving it.  If you don't wait, you may start typing in the 
wrong location, which requires undoing that, repositioning, and retyping - 
which is worse than simply waiting, and readjusting if it is in the wrong 
position.  *This forces you to slow down, and thus is very counter 
productive.*

- If I run a .py program via double click, it leaves pythonw.exe running. 
If this happens, IDLE will not start properly (with a "Socket Error: 
Connection refused" error, then a "IDLE's subprocess didn't make connection. 
Either IDLE can't start a subprocess or personal firewall software is 
blocking the connection." error), until all instances of pythonw.exe are 
shut down.

- The cursor flashes when application is not in focus.

- Ctrl+C does not appear to stop the running of a command when it is 
attempting to construct a string (for printing) of a large list.

- Typing too quickly means anything typed before the >>> prompt is ignored. 
Example:  I loaded a file into a list with l = f.readlines(), then converted 
it into a set with s = set(l), then attempted to see the length of the set 
with len(s).  But, the letters 'len' were typed before the set(l) command 
finished, thus the interpreter ran '(s)', which attempts to print the value 
of s, which pretty much hangs the interpreter - I waited on my 1.5 GHz 
machine for about 20 minutes (s length of 80,000) and it had not printed a 
single character.  Note that this occurs for the simplest commands, such as 
assignments.  It forces you to slow down, and thus is counter productive.

- When saving a new file, it does not append .py, unlike every other Windows 
application.

- Under 'Options', 'Configure IDLE', 'Fonts/Tabs', 'Set Indentation Defaults', 
if you change the default to 'Tab key inserts tabs', this setting appears to 
take place only once you restart IDLE.

- For the File Editor window, when TAB is set to insert tabs, it inserts 
spaces.  I realize this is known, as it is stated on the 'IDLE Description' 
page.  But, even if you Python source files contain 4 space indents rather 
than Tabs, there is no reason the editor cannot 'think' of them as tabs, so 
the user need not be annoyed with it.

- In the File Editor, if you load a text file with tabs, they will shows as 
actual tabs, but they are 8 spaces large (instead of 4, the default setting 
within IDLE).  Pressing delete on this '8 space tab character' changes it 
into 4 spaces (NOT a 4-space wide tab, but 4 individual spaces), as if the 
other 4 spaces were just deleted.

- When pasting code into the IDLE editor, if the cursor is moved off screen, 
the view does not change to show the new location of the cursor.  Note that 
this occurs when pasting a copied function from one file to another, or even 
when just toying with the interpreter while learning (during which the 
cursor is almost always at the bottom of the screen).

- Right clicking on a .py file, and selecting 'edit with IDLE' loads a NEW 
copy of the shell, instead of just opening it in the existing instance.

- When pressing Ctrl+H to do a search and replace, or Ctrl+F to do a search, 
the 'Find:' field is not automatically populated with the current selection.

- The buttons within the search dialogs are not standard.  The 'replace' 
button should do what the 'replace + find' does.  The Alt+F and Alt+R 
shortcuts also do not work.

- In the python.org tutorial, "6.2 Standard Modules", after "import sys", 
the commands "sys.ps1" and "sys.ps2" do not work in IDLE, only in the 
command line.  The text states that "These two variables are only defined if 
the interpreter is in interactive mode", so is IDLE not in interactive mode? 
I thought the fact you can use it as a calculator and such means that it's 
in interactive mode.

- IDLE appears to get slower as more text is drawn within its window.  You 
can notice that the program is slow merely by grabbing the window and moving 
it about the screen.  It updates about 1/10th the speed of most windows.

- Alt+Back Space does not perform 'Undo' (Ctrl+Z), but performs 'Back Space', 
instead.

- It would be extremely helpful if, when typing the 'else:' clause on a new 
line that it would automatically remove the indent, much like MS's Visual 
Studio does as soon as you type the colon within a switch statement.

- When moving the cursor up/down, the status bar display for the line number 
does not update until the cursor movement stops.  You cannot see where to 
stop on a particular line that the interpreter is complaining about easily. 
Yes, I know about Alt+G, but you may only be a few lines away and choose to 
use the cursor instead.

- Alt+G, for 'goto line', should be Ctrl+G.

- Ctrl+G in IDLE is the 'Find Next', where the standard for Windows apps is 
F3.

- It would be nice if the HOME key, within the shell, would return you to 
the end of the prompt (where you would start typing), rather than the start 
of the entire line (the beginning of the '>>>', which means you have to 
manually step past it).

- It would be nice if pressing the HOME key went to the first character that 
is not whitespace.  Then, if pressed again, will go to the first character 
on the line.  MSVC++ does this, and it is quite convenient when you want to 
move to the beginning and not have to step through spaces (especially due to 
the lack of tabs).

- From the "IDLE Description" page: "However, if you paste in a selection 
containing more than one Python statement, only the first statement will be 
sent to the interpreter when you press Enter."  It would be nice if this 
were not the case, so newbies could copy and paste sample code from 
tutorials easily.

- Function/Method Call Tips that show what parameters a function/method 
requires will disappear after you enter the closing parenthesis, but it 
remains if you remove the opening parenthesis instead -- such as if you 
decide to not use that function/method and begin typing completely different 
code.

- The 'Path Browser' shows only what sys.path equals at the start of the 
shell, not what it equals at the current time.  This is annoying because: 1. 
you cannot change it, and then use the Path Browser, and 2. because IDLE 
does not run the start up file that the 'PYTHONSTARTUP' environment variable 
points to.

- File -> Open does not remember the last directory accessed.

- For some bugs in IDLE, it has been suggested to try different switches. 
However, the shortcuts made do not show the command line.  It is hidden. 
The 'Find Target' button is grayed.  Apparently this is called 'resiliency' 
( 
http://mail.python.org/pipermail/python-bugs-list/2005-March/027966.html ), 
but it is bad, since users have no idea what command line is, so they can 
modify it.

- It would be nice if Ctrl+W selected a whole word, as in MSVC++.  However, 
understand that this is the same shortcut to close a web browser window in 
IE and Firefox.  It's a bad shortcut, yes, but it is widely used by a lot of 
people.

 - The search and replace dialog does not highlight the text it finds 
sometimes.  In particular, this happened when searching for 'print' to 
replace with '#print'.

- When you have a non-ASCII character in a file, and attempt to save it (by 
clicking save, or by trying to run it, when saves it first), the warning is 
very unintuitive.  Pressing 'Edit my file' seems to allow you - the human - 
to edit the file before saving, so you can add that text to the top 
manually.  This is not the case, it edits and saves it for you.

- Alt+O is the shortcut for both the 'Format' menu and the 'Options' menu. 
The standard would be to leave Alt+O for Format.  Something else needs to be 
set for Options.  Note that this means the main shell window will also have 
to change.  BUT, it does not have a Format menu, but it has an Options menu, 
thus people may wonder why Alt+O isn't attributed to Options.  Perhaps the 
Options menu should be called something else, or its sub items be moved 
elsewhere?

- The Insert key does not alter an insert/overwrite state.

- There is no horizontal scroll bar.

- Under the file menu, the 'close' (ALT+F4) and 'exit' (CTRL+Q) selections 
may not be intuitive.  It seems that when you open a new window, you should 
be able to close it by pressing ALT+F4, or by selecting the last selection 
in the file menu.  For instance, I routinely press ALT+F to select the 'File' 
menu, then press up, to select the last item, and press ENTER to exit. 
Making things standardize avoids ALL possible issues with ALL the different 
ways users go about doing things.  When I press ALT+F and UP and ENTER, I 
don't think 'I am selecting the last menu in the file list', I am thinking 
'close this', and my fingers do something really quickly without conscious 
thought, then it closes.  When I decide to close a new window in IDLE, my 
fingers do something that makes the whole application shut down.

- If a module is changed, no recompile is made when a file that uses it is 
run.  The compiler does not check to see if the .py file is NEWER than the 
.pyc file.  I have to specifically run it when the changes are made to force 
a recompile.


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

Ok, thanks for all of your information.  It is appreciated.

-- 
Jason Doucette / Xona.com
www.jasondoucette.com / www.xona.com


From kbk at shore.net  Thu Oct 27 19:31:27 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 27 Oct 2005 13:31:27 -0400
Subject: [Idle-dev] IDLE improvements
In-Reply-To: <000501c5d9e1$2fcbc6c0$3500a8c0@OptimusPrime> (Jason Doucette's
	message of "Wed, 26 Oct 2005 00:55:44 -0300")
References: <000a01c5cdad$898072a0$3500a8c0@OptimusPrime>
	<87achh6u56.fsf@hydra.bayview.thirdcreek.com>
	<007701c5ce9c$c75c9280$3500a8c0@OptimusPrime>
	<878xwz4ecd.fsf@hydra.bayview.thirdcreek.com>
	<000501c5d9e1$2fcbc6c0$3500a8c0@OptimusPrime>
Message-ID: <877jbyrhn4.fsf@hydra.bayview.thirdcreek.com>

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

> [....]

Jason, I'm headed out for a week or so and can't address all that
with a quick reply.  I'll do it when I get back.

-- 
KBK