From cben at users.sf.net  Thu Aug 12 21:39:02 2004
From: cben at users.sf.net (Beni Cherniavsky)
Date: Fri Aug 13 11:30:16 2004
Subject: [Idle-dev] IDLE on Jython?
Message-ID: <cfggvs$73s$1@sea.gmane.org>

Now that IDLE works with a subprocess, it should be relatively easy to
get IDLE working with Jython which sorely lacks an IDE.  The GUI would
run on CPython, while the backend process would be on Jython.  I had
barely thought of this and a Google search showed__ me Guido's Time
Machine in action <wink>:

> I happen to be working on a version of IDLE that forks off a
> subprocess to execute the code.  This idea is inspired by previous
> work of course (Bruce Sherwood c.s.) but this time I'm trying to do it
> "right".
> 
> It's not yet ready for prime time, but I believe it would be easy
> enough to add Jython support: the UI would be using CPython, but the
> user's code would run in Jython.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

__ http://mail.python.org/pipermail/idle-dev/2000-December/000251.html

Has anyone tried it?  Google didn't show any such work.  I'm going to
try it so I'd be happy to use any prior art...

Jython is frequently embedded in other apps, so it would be useful to
allow reversion of the process launch roles: the Jython half should be
able to listen on a port and launch a CPython running the GUI.  The same
thing could be useful for embedded CPython (think of a game embedding
Python; all it would have to do to open a nice IDE is call a single
function in idlelib).

From fredrik.kant at telia.com  Tue Aug 17 20:42:56 2004
From: fredrik.kant at telia.com (Fredrik kant)
Date: Tue Aug 17 20:42:58 2004
Subject: [Idle-dev] Request/Suggestion: Integrated UML editor in IDLE
Message-ID: <412251B0.7020907@telia.com>

Hi!
I have checked out some tools(Eclipse, PyUt) for working with UML and 
Python, mainly to be used for documentation, and think it would be a 
nice feature if it something like this could be integrated in IDLE.
The PyUt (I had problem to get it running but succeeded at last) could 
handle reverse engineering which is one needed basic feature.
One way we use Python is mainly to build standalone Application Service 
(as consultancy) and what I am looking for is a nice way to document 
such service.
So class diagrams and sequence diagrams would be helpful.

Any thoughts?

/Fredrik Kant


From noreply at sourceforge.net  Sun Aug 22 05:12:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 05:12:25 2004
Subject: [Idle-dev] [ idlefork-Feature Requests-761226 ] cannot reopen file
	easily
Message-ID: <E1ByimM-0004x5-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #761226, was opened at 2003-06-26 09:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579

Category: None
Group: None
Status: Open
>Resolution: None
>Priority: 2
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot reopen file easily

Initial Comment:
It is not possible to reopen a file in the editor if it is 
changed from outside. You will have to close the editor 
window and open the file again. Just open the file
in the editor will leave the contents unchanged.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-21 22:12

Message:
Logged In: YES 
user_id=149084

This is an RFE which I believe would find limited use.

Calling an Open dialog on a file which is already open
merely wakes up the associated window.  Doing what
this RFE asks would require tracking the modification
times of open files and comparing upon re-open.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579
From noreply at sourceforge.net  Sun Aug 22 06:51:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 06:51:56 2004
Subject: [Idle-dev] [ idlefork-Feature Requests-761226 ] cannot reopen file
	easily
Message-ID: <E1BykKe-00070W-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #761226, was opened at 2003-06-26 10:45
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot reopen file easily

Initial Comment:
It is not possible to reopen a file in the editor if it is 
changed from outside. You will have to close the editor 
window and open the file again. Just open the file
in the editor will leave the contents unchanged.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-22 00:51

Message:
Logged In: YES 
user_id=6380

Hm, *I* would find it extremely useful. The other editor I
use a lot has several features relating to this issue, and I
*depend* on them.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-21 23:12

Message:
Logged In: YES 
user_id=149084

This is an RFE which I believe would find limited use.

Calling an Open dialog on a file which is already open
merely wakes up the associated window.  Doing what
this RFE asks would require tracking the modification
times of open files and comparing upon re-open.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579
From noreply at sourceforge.net  Sun Aug 22 07:21:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 07:21:43 2004
Subject: [Idle-dev] [ idlefork-Bugs-754928 ] opening non-existent files -
	faults
Message-ID: <E1ByknV-0007hD-00@sc8-sf-web3.sourceforge.net>

Bugs item #754928, was opened at 2003-06-15 11:38
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=754928&group_id=9579

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Kurt B. Kaiser (kbk)
Summary: opening non-existent files - faults

Initial Comment:
This applies to idle 0.9b1 as contained within 
python cvs-version dated 2003/06/15

invoking idle on the command line by

idle -e  Test.py

where the file 'Test.py' doesn't exist yet,
opens a dialog asking whether to open a
non-existing file. That's OK

But saving this file (after entering something)
asks for the filename. IMHO it should take the
name 'Test.py' from above.

Second scenario.

Using  File - Open in the Python-Shell
and entering 'Test.py' where again
this file doesn't exist yet
pops up the same dialog but then
does NOT give me an editor window.

Thanks for idle 0.9 

jarausch@skynet.be

Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany


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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-22 00:21

Message:
Logged In: YES 
user_id=149084

First issue fixed in Python IDLE 1.1a3
FileList 1.8

Second scenario is rejected: Normal action for
Open is to reject non-existant filename.  Use
the File / New selection instead.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=754928&group_id=9579
From noreply at sourceforge.net  Sun Aug 22 07:40:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 07:40:35 2004
Subject: [Idle-dev] [ idlefork-Bugs-763524 ] Colorizing/Beeps/Focus/Crashes
	RFE/Bugs
Message-ID: <E1Byl5j-0008Je-00@sc8-sf-web3.sourceforge.net>

Bugs item #763524, was opened at 2003-06-30 17:20
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=763524&group_id=9579

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Colorizing/Beeps/Focus/Crashes RFE/Bugs

Initial Comment:
I've been using the latest version from Python CVS on
Win9: quite intensively over the last week.  Some
observations:

- When reusing a blank untitled window to edit a Text
file, it keeps using Python coloring.

- When saving a Python with a non-Python extension
(e.g. .txt), it keeps the coloring.

- When switching off coloring by saving an untitle
buffer as a non-Python extension (e.g. .txt), it keeps
existing coloring.

- When opening a file reuses a blank untitled window,
it doesn't set the focus on the window.

- I take back my earlier request to do something when
the stack viewer window can't find a traceback.  It
beeps, but I had my sound off.

- When right click -&gt; Go to file/line can't find
something, perhaps it should just beep rather than pop
up a dialog.

- Maybe anything that can't do something that's pretty
obvious should just beep?   Or maybe errors should be
displayed somehow but not require clicking OK?

- Selecting a window from the Windows menu doesn't set
the focus on the selected window!

- Keyboard shortcut for Redo (Ctl-Shift-Z) doesn't
actually work!

- Is there any way to set a breakpoint
programmatically? (the IDLE debugger equivalent of
pdb.set_trace())

- I think I crashed it by using the stack viewer after
closing the PyShell.

- It also crashed occasionally when using the debugger
(after many successful debug sessions).

- stack browser window needs title (currently says &quot;idle&quot;)

- debugger doesn't always pop up when started

- source window doesn't always pop up when double
clicking in debugger

- want a &quot;save all&quot; in file menu.

- suspending win98 has high probability of crashing
idle when a subprocess exists (?)


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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-22 00:40

Message:
Logged In: YES 
user_id=149084

Addressed the two focus issues: reuse of blank window
and Windows menu now grab focus.

Addressed the two window raising issues in debugger.

Fixed in Python IDLE 1.1a3.
WindowList.py Rev 1.6 and associated changes.

Redo shortcut was fixed in Python IDLE 1.1a1.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-07-01 06:40

Message:
Logged In: YES 
user_id=6380

2. There's a special feature that if you have a blank,
unchanged, untitled window (e.g. created by ^N) and then
from within that window open a file, the opened file reuses
the blank window rather than creating a new window like it
normally does. Apparently a few settings aren't correctly
set/reset in this case.

3. Agreed.

4. So true. It's fine to ignore it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-07-01 01:30

Message:
Logged In: YES 
user_id=149084

1. Rather than aggravate the list with endless copies of
this tracker every time one gets fixed, I'm going to add
the items to the TODO with a final disposition here when
all fixed (or not :)
2. I can't reproduce the first item.  What does &quot;reusing a
blank, untitled...&quot; mean? Exactly what did you do to get
to that point?
3. Generally, I like a quiet interface.   I don't like dialogs
popping up when I'm just being stupid or trying something
to see if it's possible.  Beeps are ok, I just turn the sound
down.  Of course some people like to listen to music, so 
I suppose we'll need a config option at some point.
4. In my experience, suspending W98 has a high probability
of crashing, period.  I'm not sure how I'd attack that one.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=763524&group_id=9579
From noreply at sourceforge.net  Sun Aug 22 08:37:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 08:37:27 2004
Subject: [Idle-dev] [ idlefork-Bugs-740041 ] Windows location of .idlerc
Message-ID: <E1Bylym-0007BR-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
>Resolution: Works For Me
Priority: 6
Submitted By: Bruce Sherwood (bsherwood)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Windows location of .idlerc

Initial Comment:
Minor bug: On Windows XP, the folder .idlerc is in 
C:\Documents and Settings\Bruce Sherwood (or 
whatever user name), which seems the correct place for 
individual preferences. On Win2000 however, the folder 
is at C:\.idlerc, despite the existence of C:\Documents 
and Settings, and this is not a good place for individual 
preferences. A particularly bad consequence is that a 
user might be on an administered machine without 
permission to write to C:\.idlerc, whereas a user can 
always write to their Documents and Settings folder.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-22 01:37

Message:
Logged In: YES 
user_id=149084

on W2K my .idlerc directory is in C:|Documents and Settings\kbk

try this:

import os.path
os.path.expanduser("~")

what did you get?  Also, you should have an environment
variable HOMEPATH equal to the above dir.  Try 'set' in a
command window to see your environment.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=740041&group_id=9579
From noreply at sourceforge.net  Mon Aug 23 04:43:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 04:43:23 2004
Subject: [Idle-dev] [ idlefork-Feature Requests-761226 ] cannot reopen file
	easily
Message-ID: <E1Bz4no-0007gr-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #761226, was opened at 2003-06-26 09:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: cannot reopen file easily

Initial Comment:
It is not possible to reopen a file in the editor if it is 
changed from outside. You will have to close the editor 
window and open the file again. Just open the file
in the editor will leave the contents unchanged.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-22 21:43

Message:
Logged In: YES 
user_id=149084

Ah, yes, the /other/ editor.  Emacs, I presume, also my
/other/ editor.  Emacs has a rather sophisticated locking
feature involving symlinks which detects at the first
keystroke that another emacs has modified the file.
IDLE could interact with that implementation, but I
assume that you'd be satisfied if IDLE imitated the

 (if (buffer-modified-p buf)
 "File %s changed on disk.  Discard your edits? "
 "File %s changed on disk.  Reread from disk? ")

behavior when the disk file was modified by another
application. This would involve adding the equivalent
to (verify-visited-file-modtime buf) and an associated
EditorWindow modtime attribute.

When the file is saved IDLE could then also detect a time
mismatch and warn the user that he was about to overwrite
a modified file.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-21 23:51

Message:
Logged In: YES 
user_id=6380

Hm, *I* would find it extremely useful. The other editor I
use a lot has several features relating to this issue, and I
*depend* on them.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-21 22:12

Message:
Logged In: YES 
user_id=149084

This is an RFE which I believe would find limited use.

Calling an Open dialog on a file which is already open
merely wakes up the associated window.  Doing what
this RFE asks would require tracking the modification
times of open files and comparing upon re-open.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579
From noreply at sourceforge.net  Mon Aug 23 05:23:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 05:23:35 2004
Subject: [Idle-dev] [ idlefork-Feature Requests-761226 ] cannot reopen file
	easily
Message-ID: <E1Bz5Qi-0002Pq-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #761226, was opened at 2003-06-26 10:45
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Kurt B. Kaiser (kbk)
Summary: cannot reopen file easily

Initial Comment:
It is not possible to reopen a file in the editor if it is 
changed from outside. You will have to close the editor 
window and open the file again. Just open the file
in the editor will leave the contents unchanged.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-22 23:23

Message:
Logged In: YES 
user_id=6380

I wasn't talking about two Emacsen interacting (I rarely
have more than one running and it's almost always by
mistake). Emacs does a super job of detecting that some
other tool (e.g. source control!) touched a file. I guess
the algorithm is something like

- save the mtime when first opening
- upon first change, see if the mtime didn't change
- upon save, see again if the mtime didn't change

If the mtime did change, various interaction take place to
decide whether to cancel the operation or go ahead despite
the change.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-22 22:43

Message:
Logged In: YES 
user_id=149084

Ah, yes, the /other/ editor.  Emacs, I presume, also my
/other/ editor.  Emacs has a rather sophisticated locking
feature involving symlinks which detects at the first
keystroke that another emacs has modified the file.
IDLE could interact with that implementation, but I
assume that you'd be satisfied if IDLE imitated the

 (if (buffer-modified-p buf)
 "File %s changed on disk.  Discard your edits? "
 "File %s changed on disk.  Reread from disk? ")

behavior when the disk file was modified by another
application. This would involve adding the equivalent
to (verify-visited-file-modtime buf) and an associated
EditorWindow modtime attribute.

When the file is saved IDLE could then also detect a time
mismatch and warn the user that he was about to overwrite
a modified file.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-22 00:51

Message:
Logged In: YES 
user_id=6380

Hm, *I* would find it extremely useful. The other editor I
use a lot has several features relating to this issue, and I
*depend* on them.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-21 23:12

Message:
Logged In: YES 
user_id=149084

This is an RFE which I believe would find limited use.

Calling an Open dialog on a file which is already open
merely wakes up the associated window.  Doing what
this RFE asks would require tracking the modification
times of open files and comparing upon re-open.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=359579&aid=761226&group_id=9579