From gritsch@iue.tuwien.ac.at Wed Mar 1 14:43:53 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Wed, 01 Mar 2000 15:43:53 +0100
Subject: [Idle-dev] default font for IDLE on Linux
Message-ID: <38BD2CA9.6BAE674@iue.tuwien.ac.at>
--------------E525108F923E2ECB643E9A3A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi!
In order to provide a nice looking default font for Idle on the Linux platform
the person responsible for
EditorWindow.py maybe wants to change the code block
text['yscrollcommand'] = vbar.set
if sys.platform[:3] == 'win':
text['font'] = ("lucida console", 8)
# text['font'] = ("courier new", 10)
text_frame.pack(side=LEFT, fill=BOTH, expand=1)
text.pack(side=TOP, fill=BOTH, expand=1)
text.focus_set()
to look like
text['yscrollcommand'] = vbar.set
if sys.platform[:3] == 'win':
text['font'] = ("lucida console", 8)
# text['font'] = ("courier new", 10)
if sys.platform[:5] == 'linux':
text['font'] = ("fixed", 12)
text_frame.pack(side=LEFT, fill=BOTH, expand=1)
text.pack(side=TOP, fill=BOTH, expand=1)
text.focus_set()
Regards,
Markus
--------------E525108F923E2ECB643E9A3A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi!
In order to provide a nice looking default font for Idle on the Linux
platform the person responsible for
EditorWindow.py maybe wants to change the code block
text['yscrollcommand']
= vbar.set
if sys.platform[:3]
== 'win':
text['font'] = ("lucida console", 8)
#
text['font'] = ("courier new", 10)
text_frame.pack(side=LEFT,
fill=BOTH, expand=1)
text.pack(side=TOP,
fill=BOTH, expand=1)
text.focus_set()
to look like
text['yscrollcommand']
= vbar.set
if sys.platform[:3]
== 'win':
text['font'] = ("lucida console", 8)
#
text['font'] = ("courier new", 10)
if sys.platform[:5]
== 'linux':
text['font'] = ("fixed", 12)
text_frame.pack(side=LEFT,
fill=BOTH, expand=1)
text.pack(side=TOP,
fill=BOTH, expand=1)
text.focus_set()
Regards,
Markus
--------------E525108F923E2ECB643E9A3A--
From guido@python.org Wed Mar 1 14:53:09 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 01 Mar 2000 09:53:09 -0500
Subject: [Idle-dev] IDLE plans
Message-ID: <200003011453.JAA13833@eric.cnri.reston.va.us>
Welcome to the IDLE-DEV mailing list!
We have great plans for IDLE, and we plan to work with all of you into
making the new IDLE a big success. (I know some of you are working on
your own Python IDE; I'm happy to share sourcecode and ideas, and of
course IDLE will be released as open source as part of the Python core
distribution, meaning it will have the same license as the rest of
Python.)
Jeremy and I had a brief strategy discussion, and we came up with a
bunch of things we should tackle first.
THE DEBUGGER
We want to move to an approach where when you run your program, it
runs in a separate, fresh process. This means that we'll have to come
up with a remote debugging protocol (which will be part of the
standard Python library, for general use). I believe effbot has
already done something like this for PythonWorks -- Fredrik, care to
share your secret? The rest of the debugger needs to be overhauled as
well; see the TODO.txt file in the latest IDLE distribution for more
suggestions.
We discussed breakpoints; the conclusion is that breakpoints ought to
be stored in a (per-project) global "database". They also ought to be
displayed in the source code window in some way. When you edit a file
and move code around, the breakpoints should be recalculated and
stored back in the database.
This is going to be a major project.
PROJECT MANAGEMENT
We need project management (again, PythonWorks is a good example; but
so is VC++ or any number of Windows apps). This is relatively simple
and straightforward. Question: should there be a 1-1 correspondence
between projects and directories?
We discussed IDLE's current tendency to create lots of top-level
windows, versus a more "pane-oriented" approach. We couldn't reach a
conclusion, except that pane-oriented should probably be an option.
We decided to put off coding the pane-oriented version.
CUSTOMIZATION
IDLE really needs some better customization (the first post to this
list was about that!). I propose the following:
(1) A config file containing the major settable options; the user can
simply edit the file to change color preferences, bindings, etc.
Possibly some configuration may be overridden by a per-project config
file as well. (We *could* use the standard X11/Tk options database,
but this is awkward to use in my opinion, and only works on Unix.)
(2) (Later) a GUI for editing the preferences.
Note that this approach is similar to what we used for Grail (remember
Grail? :-). This time, however, I'd prefer to use ConfigParser.py to
parse the options file rather than rfc822.py.
NITS
We'd like to make IDLE's Emacs emulation more like Emacs (see TODO.txt
again). We could use some help in coding this up, and also could use
some suggestions about what are the most sorely needed Emacsisms. (We
already know about paren matching. :-)
Also, almost everything in the TODO.txt file is still on our list...
--Guido van Rossum (home page: http://www.python.org/~guido/)
From tony@lsl.co.uk Wed Mar 1 15:18:35 2000
From: tony@lsl.co.uk (Tony J Ibbs (Tibs))
Date: Wed, 1 Mar 2000 15:18:35 -0000
Subject: [Idle-dev] IDLE plans
In-Reply-To: <200003011453.JAA13833@eric.cnri.reston.va.us>
Message-ID: <002501bf8391$69653440$f0c809c0@lslp7o.lsl.co.uk>
Guido van Rossum wrote:
> We'd like to make IDLE's Emacs emulation more like Emacs (see TODO.txt
> again). We could use some help in coding this up, and also could use
> some suggestions about what are the most sorely needed Emacsisms. (We
> already know about paren matching. :-)
One of the things that seems to be "missing" from most (all?) Windows
editors is the ability to have multiple windows open on the same file (e.g.,
In [X]Emacs what one gets with C-X 2 (split-window-vertically)). Of course,
in the current IDLE model, (new-frame) might be a better model. It's often
invaluable to be able to look at two different places in the same file...
Personally, incremental search is my most wanted "missing thing", though -
for me it's probably the "killer app" for [X]Emacs.
Tibs
--
Tony J Ibbs (Tibs) http://www.tibsnjoan.demon.co.uk/
"How fleeting are all human passions compared with the massive
continuity of ducks." - Dorothy L. Sayers, "Gaudy Night"
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)
From gritsch@iue.tuwien.ac.at Wed Mar 1 15:27:07 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Wed, 01 Mar 2000 16:27:07 +0100
Subject: [Idle-dev] IDLE plans
References: <200003011453.JAA13833@eric.cnri.reston.va.us>
Message-ID: <38BD36CB.DAFBFB54@iue.tuwien.ac.at>
--------------A26221E7A54C1F4E30A8A08A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Guido van Rossum wrote:
> We need project management (again, PythonWorks is a good example; but
> so is VC++ or any number of Windows apps). This is relatively simple
> and straightforward. Question: should there be a 1-1 correspondence
> between projects and directories?
I think it would be very valuable to have a look at the GUI of "Forte for Java
Community Edition". This de facto standard IDE for Java from Sun has a lot of
great ideas realized in its GUI. For example it provides different views of
the Sourcecode - one includes a filesystem-based one, and another realizes a
project-based one. So I don't think there should be a 1-1 correspondence
between projects and directories.
> We discussed IDLE's current tendency to create lots of top-level
> windows, versus a more "pane-oriented" approach. We couldn't reach a
> conclusion, except that pane-oriented should probably be an option.
> We decided to put off coding the pane-oriented version.
Here again, Suns Forte4Java IDE can be used as a very well done example: The
IDEs GUI also uses lots of top-level windows (like IDLE does), but the first
time the IDE starts, it places the separate windows at appropriate locations,
so the screen isn't as much cluttered as it is by using lots of IDLE windows.
Maybe the windows of IDLE could be also placed by IDLE itself. Anyway, to
better understand what I mean, it would help to take a look at forte4java in
action.
The Call tip window which pops up when you type the name of a known function
followed by an open parenthesis. Is already very useful. Even more useful
would be a feature similar to the completion-feature in forte4java (o.k. at
this point I think I have to apologize citing forte4java features all the time,
but personally I find this IDE *very* usable, and maybe this would be the right
direction to go fot Idle): By pressing CTRL-SPC a pop-up menu comes up with
all the appropriate methods fitting to the so far typed text. To make this
clear lets say we have an object calles "myObject" whith some methods. By
typing
myObject.
^
cursor is here
and then pressing CTRL-SPC one sees all the methods myObject has to offer.
After typing
myObject.lis
^
cursor is here
and pressing CTRL-SPC, all the methids of myObject starting with "lis" are
shown, and so on.
I use this feature all the time, and it prevents me in most cases from looking
into the API.
Regards,
Markus
--
|\/\/\/|
/------------------------------------------------------------------\ | |
| Markus GRITSCH | phone: +43 / 1 / 58801-36015 | | |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431 | | (o)(o)
| Technical University of Vienna | fax: +43 / 1 / 58801-36099 | C _)
| Gusshausstrasse 27-29 / E360 | email: gritsch@iue.tuwien.ac.at | | ,___|
| A-1040 Vienna / AUSTRIA | SMS: 436764973431@max.mail.at | | /
\------------------------------------------------------------------/ /____\
/ \
"Computers let you make more mistakes faster than any other invention in human
history, with the possible exception of handguns and tequila."
Mitch Radcliffe
--------------A26221E7A54C1F4E30A8A08A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Guido van Rossum wrote:
We need project management (again, PythonWorks is
a good example; but
so is VC++ or any number of Windows apps). This is relatively
simple
and straightforward. Question: should there be a 1-1 correspondence
between projects and directories?
I think it would be very valuable to have a look at the GUI of "Forte for
Java Community Edition". This de facto standard IDE for Java from Sun has
a lot of great ideas realized in its GUI. For example it provides
different views of the Sourcecode - one includes a filesystem-based one,
and another realizes a project-based one. So I don't think there
should be a 1-1 correspondence between projects and directories.
We discussed IDLE's current tendency to create lots
of top-level
windows, versus a more "pane-oriented" approach. We couldn't
reach a
conclusion, except that pane-oriented should probably be an option.
We decided to put off coding the pane-oriented version.
Here again, Suns Forte4Java IDE can be used as a very well done example:
The IDEs GUI also uses lots of top-level windows (like IDLE does), but
the first time the IDE starts, it places the separate windows at appropriate
locations, so the screen isn't as much cluttered as it is by using lots
of IDLE windows. Maybe the windows of IDLE could be also placed by
IDLE itself. Anyway, to better understand what I mean, it would help
to take a look at forte4java in action.
The Call tip window which pops up when you type the name of a known
function followed by an open parenthesis. Is already very useful.
Even more useful would be a feature similar to the completion-feature in
forte4java (o.k. at this point I think I have to apologize citing forte4java
features all the time, but personally I find this IDE *very* usable, and
maybe this would be the right direction to go fot Idle): By pressing
CTRL-SPC a pop-up menu comes up with all the appropriate methods fitting
to the so far typed text. To make this clear lets say we have an
object calles "myObject" whith some methods. By typing
myObject.
^
cursor is here
and then pressing CTRL-SPC one sees all the methods myObject has to
offer. After typing
myObject.lis
^
cursor is here
and pressing CTRL-SPC, all the methids of myObject starting with "lis"
are shown, and so on.
I use this feature all the time, and it prevents me in most cases from
looking into the API.
Regards,
Markus
--
|\/\/\/|
/------------------------------------------------------------------\ | |
| Markus GRITSCH | phone: +43 / 1 / 58801-36015 | | |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431 | | (o)(o)
| Technical University of Vienna | fax: +43 / 1 / 58801-36099 | C _)
| Gusshausstrasse 27-29 / E360 | email: gritsch@iue.tuwien.ac.at | | ,___|
| A-1040 Vienna / AUSTRIA | SMS: 436764973431@max.mail.at | | /
\------------------------------------------------------------------/ /____\
/ \
"Computers let you make more mistakes faster than any other invention in human
history, with the possible exception of handguns and tequila."
Mitch Radcliffe
--------------A26221E7A54C1F4E30A8A08A--
From gerrit@nl.linux.org Wed Mar 1 15:38:34 2000
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Wed, 1 Mar 2000 16:38:34 +0100
Subject: [Idle-dev] IDLE plans
In-Reply-To: <38BD36CB.DAFBFB54@iue.tuwien.ac.at>; from gritsch@iue.tuwien.ac.at on Wed, Mar 01, 2000 at 04:27:07PM +0100
References: <200003011453.JAA13833@eric.cnri.reston.va.us> <38BD36CB.DAFBFB54@iue.tuwien.ac.at>
Message-ID: <20000301163834.A7919@nl.linux.org>
> Guido van Rossum wrote:
>
> > We need project management (again, PythonWorks is a good example; but
> > so is VC++ or any number of Windows apps). This is relatively simple
> > and straightforward. Question: should there be a 1-1 correspondence
> > between projects and directories?
I don't think so - I think it should be as flexible as possible.
> The Call tip window which pops up when you type the name of a known function
> followed by an open parenthesis. Is already very useful.
> Even more useful would be a feature similar to the completion-feature
> in forte4java.
In fact, this already exists somewhere:
>>> import rlcompleter
>>> import readline
>>> readline.parse_and_bind("tab: complete")
I think it's useful for Idle though, because this one isn't really
crossplatform - the readline module need to be compiled in, which isn't
default (and what about non-unices???).
regards,
Gerrit.
--
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----
From gritsch@iue.tuwien.ac.at Wed Mar 1 15:58:59 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Wed, 01 Mar 2000 16:58:59 +0100
Subject: [Idle-dev] IDLE plans
References: <200003011453.JAA13833@eric.cnri.reston.va.us> <38BD36CB.DAFBFB54@iue.tuwien.ac.at> <20000301163834.A7919@nl.linux.org>
Message-ID: <38BD3E43.E36094D1@iue.tuwien.ac.at>
Gerrit Holl wrote:
> > Even more useful would be a feature similar to the completion-feature
> > in forte4java.
>
> In fact, this already exists somewhere:
>
> >>> import rlcompleter
> >>> import readline
> >>> readline.parse_and_bind("tab: complete")
I know, but this only works in an interactive python shell. What I meant was that
it would be nice to have this feature in an editor-like environment like IDLE is.
Kind regards,
Markus
From faassen@vet.uu.nl Wed Mar 1 16:16:14 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Wed, 1 Mar 2000 17:16:14 +0100
Subject: [Idle-dev] Looking over someone's shoulder
Message-ID: <20000301171614.A15920@vet.uu.nl>
Hi there,
During my stay in the US I've been teaching some people Python, but
sadly I'm in the Netherlands again and it is hard to continue their
education without my ability to look over their shoulders.
It would therefore be very nice if IDLE had somekind of facility to
connect to some other IDLE elsewhere on the net, and synchronize the
contents of a window with it. I don't much care if they're constant
updates or if some 'send' button needs to be pressed; perhaps both
options could be supplied.
This way I can look over the shoulders of students while they're experimenting
with Python code, even though said students are in the US and I'm in Europe.
It would be even nicer if I could go in and change their code for them.
This feature may also be useful if you want to share code snippets
with others on the net.
I haven't seen other IDEs which can do this, but I think things like
this could be nice to have in a real life course setting as well. It might be
a nice way to monitor the progress of students (who are sitting behind
PCs) from a central location.
Generalized, perhaps settings somewhat like this:
username password domain access
faassen foobar vet.uu.nl read/write
guido barfoo python.org read
timbot PSU anywhere read/write
I'm not sure if this sharing should be on file basis, project basis or
window basis, but you all hopefully get the general idea.
Regards,
Martijn
From gritsch@iue.tuwien.ac.at Wed Mar 1 16:52:43 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Wed, 01 Mar 2000 17:52:43 +0100
Subject: [Idle-dev] customizable Path/Class-browser mode
Message-ID: <38BD4ADB.DB50B336@iue.tuwien.ac.at>
Hi!
I think it should be customizable which kind of views for the browsers is
used. Some people (including me) prefere the look-and-feel which was present
in Idle0.4, some like the Directory based view more.
Regards, Markus
From smorris@nexen.com Wed Mar 1 17:32:10 2000
From: smorris@nexen.com (Steve Morris)
Date: Wed, 1 Mar 2000 12:32:10 -0500 (EST)
Subject: [Idle-dev] Looking over someone's shoulder
Message-ID: <200003011732.MAA10515@brocade.nexen.com>
Martijn Faassen writes:
> Hi there,
> It would therefore be very nice if IDLE had somekind of facility to
> connect to some other IDLE elsewhere on the net, and synchronize the
> contents of a window with it. I don't much care if they're constant
> updates or if some 'send' button needs to be pressed; perhaps both
> options could be supplied.
>
> This way I can look over the shoulders of students while they're experimenting
> with Python code, even though said students are in the US and I'm in Europe.
> It would be even nicer if I could go in and change their code for them.
I think this is a good general idea, sort of like the trainer yoke in
an airplane. I can imaging a remote teacher jumping from desktop to
desktop of their remote students. If you allowed multiple connections
this would let multiple students to watch the teachers machine.
However there are currently available solutions that solve this
problem in a more general way so maybe it shouldn't be in Idle
directly. I am specifically thinking of VNC. This is a protocol that
allows viewing and controlling one desktop from another. It requires a
server to be running on the system with the desktop. Then the virtual
desktop can be viewed and operated from any other machine, i.e. a Mac
desktop can be viewed from a UNIX machine, a UNIX X11 session can be
viewed from a Palm Pilot etc. Multiple viewers can also look at the
same desktop.
I am surprised that VNC doesn't seem to get much use in the education
world. It is sourceware under the GNU license and viewers are
available on almost any conceivable platform, including palmtops.
Servers are less common but they cover all the major platforms.
The downside is that it is slower than X11 and the like because it is
purely bit oriented. On a slow connection it is quite painful. A lot
of work is done to compress updates and narrow them down to only
required ones but this only takes you so far. Still I find it useful
to connect to my home system occasionally.
If you want to check it out the home web site is:
http://www.uk.research.att.com/vnc/index.html
A personal note:
When I installed it I couldn't resist the test of letting two desktops
look at each other, sort of like letting two mirrors face each
other. It was unbelievably slow but it worked as long as I hade the
patience to wait. I suppose it would have stopped when the included
images of included images dropped off the screen (the window border
causes an offset every pass) but that would have taken too long with
my slow connection. I was impressed.
From bas@andrew.cmu.edu Wed Mar 1 19:09:36 2000
From: bas@andrew.cmu.edu (Bruce Sherwood)
Date: Wed, 01 Mar 2000 14:09:36 -0500
Subject: [Idle-dev] Remote consulting
In-Reply-To: <20000301170058.79AC51CE8D@dinsdale.python.org>
Message-ID: <2732004204.951919776@MUON.PC.CC.CMU.EDU>
Concerning the suggestion of making it possible for a teacher of Python to
look over the shoulder of a student at a distance, I know of an example of
this that worked well.
The PLATO IV computer-based education system implemented at the University
of Illinois in the early 1970's had a "consult" feature of this kind. A
remote teacher who was writing courseware in the TUTOR language could page
an individual (or anyone on the consultant list at that moment) and offer
the consultant their screen. The two people could then carry on a (typed)
dialog in a separate window. Both source and execution windows could be
viewed by the consultant. The consultant couldn't change anything but
merely suggested things to change or do. This was a valuable, heavily used
feature.
Bruce Sherwood
From Robin.Friedrich@pdq.net Wed Mar 1 19:18:43 2000
From: Robin.Friedrich@pdq.net (Robin Friedrich)
Date: Wed, 1 Mar 2000 13:18:43 -0600
Subject: [Idle-dev] IDLE plans
References: <200003011453.JAA13833@eric.cnri.reston.va.us>
Message-ID: <00a101bf83b2$fa2e0300$f25728a1@UNITEDSPACEALLIANCE.COM>
After reviewing the TODO.txt file I've come up with a few items of
improvement.
(Eventhough I love IDLE already and use it all the time.)
Things I'd like to see:
- I'd like support for shift-click extending the selection. There's a
bug now that
it doesn't work the first time you try it.
- Printing is needed. How hard can that be on Windows?
- The python-mode trick of autoindenting a line with is neat and
very handy.
- (someday) a spellchecker for docstrings and comments.
- a pagedown/up command key which moves to next class/def statement (top
level)
- split window capability
- DnD text relocation/copying
Things I don't want to see.
- line numbers... will probably slow things down way too much.
- Please use another icon for the tree browser leaf. The small snake
isn't cutting it.
Ciao
From romberg@fsl.noaa.gov Wed Mar 1 19:29:58 2000
From: romberg@fsl.noaa.gov (Mike Romberg)
Date: Wed, 1 Mar 2000 12:29:58 -0700
Subject: [Idle-dev] Re: IDLE plans
Message-ID: <200003011929.MAA01457@smaug.fsl.noaa.gov>
> NITS
> We'd like to make IDLE's Emacs emulation more like Emacs (see TODO.txt
> again). We could use some help in coding this up, and also could use
> some suggestions about what are the most sorely needed Emacsisms. (We
> already know about paren matching. :-)
The one emacs emulation kind of thing that I think would be really
useful and more important than just cosmetic stuff is to provide hooks
into the guts of idle the same way emacs does. Emacs can be extended
and customized very easily because most modes provide these
(documented) hooks.
The group I am working with uses an embeded python to customize our
application. We allow our users to write small python functions to
perform manipulations on various weather elements. This works great
and our users (national weather service forecasters) really like the
power and flexibility.
When they edit this python code, we fire up idle (not as a separate
process but in our same interpreter). The problem is that we had to
override some of the default menu items (like close/exit). We did not
want our whole application to stop when the idle window was shut
down. In addition we wished to take some additional actions after the
code was edited. We were able to do this by examining the current
idle code and overriding some of the call backs. But this is kinda
ugly. It would be much nicer if IDLE had some hooks to do these kind
of things. Since IDLE is still in its early stages, perhaps this
would be a good time to start doing this kind of thing. I think an
emacs like editor which uses python instead of lisp would be much
easier to deal with for most users.
Mike Romberg (romberg@fsl.noaa.gov)
From gerrit@nl.linux.org Wed Mar 1 19:40:54 2000
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Wed, 1 Mar 2000 20:40:54 +0100
Subject: [Idle-dev] IDLE plans
In-Reply-To: <00a101bf83b2$fa2e0300$f25728a1@UNITEDSPACEALLIANCE.COM>; from Robin.Friedrich@pdq.net on Wed, Mar 01, 2000 at 01:18:43PM -0600
References: <200003011453.JAA13833@eric.cnri.reston.va.us> <00a101bf83b2$fa2e0300$f25728a1@UNITEDSPACEALLIANCE.COM>
Message-ID: <20000301204054.C16094@nl.linux.org>
> - I'd like support for shift-click extending the selection. There's a
> bug now that
> it doesn't work the first time you try it.
> - Printing is needed. How hard can that be on Windows?
> - The python-mode trick of autoindenting a line with is neat and
> very handy.
> - (someday) a spellchecker for docstrings and comments.
> - a pagedown/up command key which moves to next class/def statement (top
> level)
> - split window capability
> - DnD text relocation/copying
- Being able to double click (maybe double right click) on a
callable object in the editor which shows the source of
the object, if possible.
regards,
Gerrit.
--
Plis korekt eni ingglisj joe encounter in mai imeel meeasj!
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----
From faassen@vet.uu.nl Wed Mar 1 21:45:37 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Wed, 1 Mar 2000 22:45:37 +0100
Subject: [Idle-dev] Looking over someone's shoulder
In-Reply-To: <200003011732.MAA10515@brocade.nexen.com>
References: <200003011732.MAA10515@brocade.nexen.com>
Message-ID: <20000301224537.A2605@vet.uu.nl>
[I suggest people can show code in the editor to people elsewhere on the
net (and remote editing would be nice too)]
Steve Morris wrote:
> I think this is a good general idea, sort of like the trainer yoke in
> an airplane. I can imaging a remote teacher jumping from desktop to
> desktop of their remote students. If you allowed multiple connections
> this would let multiple students to watch the teachers machine.
Right!
> However there are currently available solutions that solve this
> problem in a more general way so maybe it shouldn't be in Idle
> directly. I am specifically thinking of VNC. This is a protocol that
> allows viewing and controlling one desktop from another. It requires a
> server to be running on the system with the desktop. Then the virtual
> desktop can be viewed and operated from any other machine, i.e. a Mac
> desktop can be viewed from a UNIX machine, a UNIX X11 session can be
> viewed from a Palm Pilot etc. Multiple viewers can also look at the
> same desktop.
VNC certainly looks very cool! I've played some with it today and it
will certainly get a use for me. I still have to play with the desktop
sharing feature though.
That said, I'll still argue for inclusion of this feature into IDLE itself.
One reason is that you can send plaintext over the wire instead of pixels,
which will make synching a lot faster than VNC, but that's not the
most important reason.
Showing someone your Python code should be easy, as easy as possible. This
way you'll get network effects. VNC, while it's certainly fairly easy to
install and use as far as I've seen, is still a huge step further for
newbies who just managed to install IDLE.
Network effects are very important. Take for instance the advent of the
web. Before the web, it wasn't too hard to FTP files and documents. Using
FTP isn't all that hard once you know it. Still it took the web browser
(a program for viewing documents that has a built-in document download
facility -- http) to really make the net fit for the masses.
Take Napster, very popular and scaring the heck out of the record
industry. It's basically a tool to share MP3 files with others on the net.
This was always possible, but though easy, not easy _enough_. You had to do
too much by hand.
If you could do a Napsterish thing with IDLE (somekind of connection to all
people using IDLE in the world right now :), you might be able to pull off
something rather amazing for Python programming.
This was my philosophical rant without evidence. See Bruce Sherwood's post
on PLATO's remote consulting feature for actual substance. :)
Regards,
Martijn
From Moshe Zadka Wed Mar 1 22:39:03 2000
From: Moshe Zadka (Moshe Zadka)
Date: Thu, 2 Mar 2000 00:39:03 +0200 (IST)
Subject: [Idle-dev] IDLE plans
In-Reply-To: <200003011453.JAA13833@eric.cnri.reston.va.us>
Message-ID:
On Wed, 1 Mar 2000, Guido van Rossum wrote:
> PROJECT MANAGEMENT
>
> We need project management (again, PythonWorks is a good example; but
> so is VC++ or any number of Windows apps). This is relatively simple
> and straightforward. Question: should there be a 1-1 correspondence
> between projects and directories?
A resounding NO!. Sun WorkShop assumes one project per directory: it
caused us a maintainance nightmare. I'm always going for the "mechanism,
not policy" direction, so I'm all for a seperate file for project
definition.
Big question: what should be in such a file?
I once started thinking of doing this, but it sort of got lost in the
noise, so don't count on me. I might come up with something, and I might
not.
Suggestion: the syntax should be declarative, and there should be
a pre-processor. Both seem like tautologies to me: please mail me
personally for rationale.
> We discussed IDLE's current tendency to create lots of top-level
> windows, versus a more "pane-oriented" approach. We couldn't reach a
> conclusion, except that pane-oriented should probably be an option.
> We decided to put off coding the pane-oriented version.
In Windows I usually use PythonWin purely because of the panes. Just a
data point. (As I'm not the "E" in CP4E, you might want to ignore me: I've
just learned I'm the worst at anticipating regular users)
> CUSTOMIZATION
...
> (1) A config file containing the major settable options; the user can
> simply edit the file to change color preferences, bindings, etc.
.....
The syntax doesn't matter much: location does. Where do you put
configuration files? This is a much harder problem then most people think.
(We've just ran into this problem in my company: our solutions were
different then what Python might adopt, because the situation is
different. The only global lesson for this is that it is a hard problem)
Here's a possible scheme:
Users on Unix-ish, MacOS and Win32 each have their own expectations.
Python's IDE would do well to do what Python does -- integrate into the
environment.
On UNIXish platforms, the file should be searched in:
$IDLERC, if such a variable exists, otherwise in
$HOME/.idlerc if such a file exists, otherwise in
/etc/idlerc. The location of the last file is *easily* fixed at IDLE
installation time. Ideally, IDLE's install script takes the option from
the user.
On Win9x platforms, you should have some solution involving the
environment and the registry, in that order.
On WinNT/2000 platforms, you should take the Win9x platform, and mix in
\Users\Profiles\.... in some random way
On Mac platforms, do whatever Mac guys do (no idea)
Any new platform should be considered UNIX-ish until proved innocent
(probably safe). The whole mechanism should be easily pluggable via
dynamically deciding which module which implements a "configuration file"
class to import at run-time based on the platform. (Think os.path
mechanism here).
Well, that was long winded, but hey, I warned you it's a touch subject.
--
Moshe Zadka .
INTERNET: Learn what you know.
Share what you don't.
From mhammond@skippinet.com.au Wed Mar 1 23:40:15 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Thu, 2 Mar 2000 10:40:15 +1100
Subject: [Idle-dev] Small patch to AutoExpand.py
Message-ID:
While using the auto-expand feature, it struck me that it really should also
match against builtin names.
Eg, if I enter "Index" and select auto-complete, IndexError should appear,
even if it doesnt exist in the source file.
Does anyone else agree?
If so, here is a patch :-)
Mark.
===================================================================
RCS file: /home/cvsroot/PyWin32/Pythonwin/pywin/idle/AutoExpand.py,v
retrieving revision 1.1
diff -r1.1 AutoExpand.py
67,68d66
< if not wbefore and not wafter:
< return []
83a82,85
> # Add builtin names.
> bi_filter = lambda name, word=word : string.find(name, word)==0
> bi_names = filter(bi_filter, __builtins__.keys())
> words.extend(bi_names)
From guido@python.org Thu Mar 2 01:18:20 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 01 Mar 2000 20:18:20 -0500
Subject: [Idle-dev] Small patch to AutoExpand.py
In-Reply-To: Your message of "Thu, 02 Mar 2000 10:40:15 +1100."
References:
Message-ID: <200003020118.UAA16345@eric.cnri.reston.va.us>
> While using the auto-expand feature, it struck me that it really should also
> match against builtin names.
>
> Eg, if I enter "Index" and select auto-complete, IndexError should appear,
> even if it doesnt exist in the source file.
>
> Does anyone else agree?
Hmm, I thought, that's more a task for control-space (name-expand or
something like that). E.g. Emacs has both and they are usefully
different.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From mhammond@skippinet.com.au Thu Mar 2 03:54:52 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Thu, 2 Mar 2000 14:54:52 +1100
Subject: [Idle-dev] Small patch to AutoExpand.py
In-Reply-To: <200003020118.UAA16345@eric.cnri.reston.va.us>
Message-ID:
> Hmm, I thought, that's more a task for control-space (name-expand or
> something like that). E.g. Emacs has both and they are usefully
> different.
I dont really see how they are different - but then again Pythonwin spoils
me :-)
In Pythonwin, auto-expand is really only useful for name lookups, not item
expansion. As soon as you hit "." in Pythonwin, it looks for a real object
to get a list of attributes from. If it cant find a real object, it uses
the context in the current source file to "guess" the attributes - and it
does a pretty good job.
Thus:
* all my names are usually only 3 characters, then auto-expand.
* all my attributes are one or 2 characters until the list-box selects the
item, then tab.
So I can't really think of what another different, but useful feature would
look like? And as I use auto-expand only for name lookup, I figured that it
may as well do _all_ name lookups :-)
Doesnt worry me tho - just seemed like a small and obvious feature :-)
Mark.
From tim_one@email.msn.com Thu Mar 2 05:01:41 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 2 Mar 2000 00:01:41 -0500
Subject: [Idle-dev] Small patch to AutoExpand.py
In-Reply-To:
Message-ID: <000c01bf8404$65c35920$732d153f@tim>
[Mark Hammond]
> While using the auto-expand feature, it struck me that it really
> should also match against builtin names.
>
> Eg, if I enter "Index" and select auto-complete, IndexError should
> appear, even if it doesnt exist in the source file.
>
> Does anyone else agree?
Guido notwithstanding , I agree. "Complete a name" is a single
concept in my head, not helped by Emacs-like prissy distinctions attached to
yet another batch of key bindings. The way to make this pleasant *and*
useful is to (over time) increase a single function's context awareness.
BTW, I've written word-completion pkgs for several editors that lacked the
feature, and one of the most valuable things you can do for programmers is
to search *other* open buffers for names too (e.g., picture editing a .cpp
file where a heavily used .h file is open in another buffer). When it gets
to this stage, it's also valuable to display a status msg giving the file
name & line number of the currently-suggested completion.
every-feature-becomes-a-world-of-its-own-ly y'rs - tim
From tim_one@email.msn.com Thu Mar 2 05:02:20 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 2 Mar 2000 00:02:20 -0500
Subject: [Idle-dev] IDLE plans
In-Reply-To:
Message-ID: <000d01bf8404$7d657540$732d153f@tim>
[Guido]
> PROJECT MANAGEMENT
>
> We need project management (again, PythonWorks is a good example; but
> so is VC++ or any number of Windows apps). This is relatively simple
> and straightforward. Question: should there be a 1-1 correspondence
> between projects and directories?
[Moshe Zadka]
> A resounding NO!. Sun WorkShop assumes one project per directory: it
> caused us a maintainance nightmare. I'm always going for the "mechanism,
> not policy" direction, so I'm all for a seperate file for project
> definition.
I took the "relatively simple and straightforward" in the original merely as
evidence that Guido and Jeremy never implemented project management features
before <0.7 wink>. In the end, e.g., I want an invisible database
incrementally tracking every occurrence of every symbol in my project, for
instant project-wide search, replace and cross-reference. Like Emacs
etags, but much more comprehensive and with no manual "oops -- guess you
forgot to run etags" steps. The commercial Source Insight editor for
Windows (http://www.sourcedyn.com/) is the best of this flavor I've seen,
and is the single most useful tool I've ever found for dealing with messy C
and C++ projects. Powerful "project management" gimmicks account for the
bulk of its unique value.
BTW, in Real Corporate Life, I find that "a single project" often spans not
only multiple directories, but also multiple networked machines (e.g., test
data on the "test data" machine, specs on the "doc machine", etc).
> ...
> The syntax doesn't matter much: location does. Where do you put
> configuration files? This is a much harder problem then most people think.
> (We've just ran into this problem in my company: our solutions were
> different then what Python might adopt, because the situation is
> different. The only global lesson for this is that it is a hard problem)
Source Insight solved this with a brilliantly simple scheme: at the time
you create a project, it forces *you* to specify the directory into which it
will place all its project management files. There's another file
containing these "project name" -> project management file directory"
mappings, that lives in the same directory as the editor executable, and you
can't change that assumption. This does create a hard problem if you want
to make a single copy of the executable available to multiple users (all
their project->directory mappings end up in this single file, stomping on
each other). Its answer to this is also magically simple: don't do that
.
disk-space-is-almost-free-now-ly y'rs - tim
From gerrit@nl.linux.org Thu Mar 2 07:31:37 2000
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Thu, 2 Mar 2000 08:31:37 +0100
Subject: [Idle-dev] IDLE plans
In-Reply-To: ; from moshez@math.huji.ac.il on Thu, Mar 02, 2000 at 12:39:03AM +0200
References: <200003011453.JAA13833@eric.cnri.reston.va.us>
Message-ID: <20000302083136.A7696@nl.linux.org>
> On UNIXish platforms, the file [idlerc] should be searched in:
>
> $IDLERC, if such a variable exists, otherwise in
> $HOME/.idlerc if such a file exists, otherwise in
> /etc/idlerc. The location of the last file is *easily* fixed at IDLE
> installation time. Ideally, IDLE's install script takes the option from
> the user.
I don't think so:
First, /etc/idlerc if it exists,
Next, either $IDLERC or $HOME/.idlerc to overwrite it - that's what most
Unix tools do.
regards,
Gerrit.
--
Plis korekt eni ingglisj joe encounter in mai imeel meeasj!
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----
From hei@adtranzsig.de Thu Mar 2 08:27:00 2000
From: hei@adtranzsig.de (Dirk-Ulrich Heise)
Date: Thu, 2 Mar 2000 09:27:00 +0100
Subject: [Idle-dev] Position info (Brkpoints)
Message-ID: <01bf8421$14e93c00$13ec1fc2@pc696.adtranzsig.de>
Guido mentioned the need of a global
database for tracking persistent brkpoint positions.
In an editor i'm writing i needed to track positions
for folding. I didn't like the Origami approach of
leaving strange comments in the files; this changes
the file, and the editor has to know about the language
to make a valid comment. (Don't know if Origami
still does it that way, i had a copy about 7 years ago)
My solution was to store the line number and the
trimmed content of the line together in an ASCII file.
(trimmed off whitespace at start and end of line)
On startup, the editor can check the content of the file
it loads at the given line number; if the content equals
the one stored in the "data base", it's ok, otherwise,
the file might have been changed by a second editor,
and you can now try to seek neighbouring lines for
the content you expect. If the distance gets too big
during this seeking, say, more than 20 lines, the
re-synching process would be aborted, and the fold
deleted.
During editing, the positions (just like for a breakpoint,
only the line number is considered important) are
updated by the editors operations.
Although only one line of context is stored for
each position, this scheme works very nice for my folds:
I'm able to
fold any kind of program source, the editor will not
mess up the file, and you can even make (small) edits
with other tools without losing all the folding info.
Of course, it works not very well when the position is on an
empty line; but for your breakpoints, this will not be
the case, anyway.
If you favor that approach, i could submit some C++
snippets that figure out the peculiarities of the re-synching
and the likes. (No heavy template magic or the likes,
should be straightforward to re-code in Python)
Dirk
From barmeier@BARMEIER.COM Thu Mar 2 08:58:32 2000
From: barmeier@BARMEIER.COM (Matthias Barmeier)
Date: Thu, 2 Mar 2000 09:58:32 +0100
Subject: [Idle-dev] Extends an events
Message-ID:
Hi,
I am fairly new to Tcl/Tk and Python programming.
I thin over adding a "Recent files" list for the IDLE file menu.
My first thought was to use extend.py but I dont know how I can capture
the "Open event".
Is this possible with extend.py ???
If this is not already possible to capture the menu events without changeing
the
IDLE Source I think this should be added.
Such a feature is very usefull for file locking or check in / check out
mechanisms.
/*
Dipl.-Inform. Matthias Barmeier Tel: +49 (0)30 79 70 72 87
Büro für Softwareentwicklung Fax +49 (0)30 79 70 72 88
Grunewaldstr. 18 Email: barmeier@barmeier.com
12165 Berlin WWW:
*/
From Albert.Brandl@edvg.co.at Thu Mar 2 09:05:40 2000
From: Albert.Brandl@edvg.co.at (Albert Brandl)
Date: Thu, 2 Mar 2000 10:05:40 +0100
Subject: Antwort: [Idle-dev] IDLE plans
Message-ID:
Hi!
>We discussed IDLE's current tendency to create lots of top-level
>windows, versus a more "pane-oriented" approach. We couldn't reach a
>conclusion, except that pane-oriented should probably be an option.
>We decided to put off coding the pane-oriented version.
Panes are most helpful when there are different views at the same
thing. An example: Homesite, a very powerful HTML editor has two
panes for each file: One with the HTML text editor, the other with a
view of the result (actually, an embedded Internet Explorer).
If IDLE has different views of the same information that need not
be accessed at the same time, grouping them by panes thus might be
a good idea. Assume that it is necessary to provide an overview of
a source file which only contains the class and method names
together with their doc-strings. This overview could be placed on
one pane, and the code on the other pane.
This approach would IMHO make no sense for the class browser. Here,
it's essential that both the source editor and the browser are
accessible at the same time. Still, they are strongly coupled -
I think you should consider to replace the two top-level windows
with one, bigger window. This would create a much stronger visual
connection of the two elements and thus prevent the user from
searching around the screen for that darn class browser ;-)
Regards,
Albert
From Albert.Brandl@edvg.co.at Thu Mar 2 09:06:01 2000
From: Albert.Brandl@edvg.co.at (Albert Brandl)
Date: Thu, 2 Mar 2000 10:06:01 +0100
Subject: [Idle-dev] IDLE interpreter window
Message-ID:
Hi!
Up to now, I haven't used the IDLE interpreter
window much. I've always felt a bit unconfortable
about its handling, but it took me some time to
figure out why.
The main reason is that it's hard for me to become
used to the lack of control I have with the keyboard.
In order to repeat a command I have to select it
and copy-and-paste it at the right position - yukk!
In other words: The interpreter window does not
resemble the usual terminal windows (be it msdos
or unix) very well.
I do not see any advantage with the current
approach - except that it's easier to code :-)
So maybe "Improve the interpreter command
line behaviour" should be another item on
the todo list.
Yours,
Albert
From gritsch@iue.tuwien.ac.at Thu Mar 2 10:11:25 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Thu, 02 Mar 2000 11:11:25 +0100
Subject: [Idle-dev] IDLE interpreter window
References:
Message-ID: <38BE3E4D.6E357F4C@iue.tuwien.ac.at>
Albert Brandl wrote:
> So maybe "Improve the interpreter command
> line behaviour" should be another item on
> the todo list.
I think having a feature like Pythonwin's CTRL+UP and CTRL+DOWN (with which you
can access the command history) here would help.
--
Markus
From gerrit@nl.linux.org Thu Mar 2 11:11:19 2000
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Thu, 2 Mar 2000 12:11:19 +0100
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To: <38BE3E4D.6E357F4C@iue.tuwien.ac.at>; from gritsch@iue.tuwien.ac.at on Thu, Mar 02, 2000 at 11:11:25AM +0100
References: <38BE3E4D.6E357F4C@iue.tuwien.ac.at>
Message-ID: <20000302121118.A14280@nl.linux.org>
> Albert Brandl wrote:
>
> > So maybe "Improve the interpreter command
> > line behaviour" should be another item on
> > the todo list.
>
> I think having a feature like Pythonwin's CTRL+UP and CTRL+DOWN (with which you
> can access the command history) here would help.
I think "modes" should be useful. I prefer to have my shell in "vi mode",
others will prefer emacs mode.
regards,
Gerrit.
--
Plis korekt eni ingglisj joe encounter in mai imeel meeasj!
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----
From mhammond@skippinet.com.au Thu Mar 2 11:12:29 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Thu, 2 Mar 2000 22:12:29 +1100
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To: <38BE3E4D.6E357F4C@iue.tuwien.ac.at>
Message-ID:
> > So maybe "Improve the interpreter command
> > line behaviour" should be another item on
> > the todo list.
>
> I think having a feature like Pythonwin's CTRL+UP and CTRL+DOWN
> (with which you
> can access the command history) here would help.
hehe - Id love to take the credit, but I stole them from IDLE - isnt it
Alt-N and Alt-P or something?
Implemented in IdleHistory.py...
Mark.
From gritsch@iue.tuwien.ac.at Thu Mar 2 11:35:06 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Thu, 02 Mar 2000 12:35:06 +0100
Subject: [Idle-dev] IDLE interpreter window
References:
Message-ID: <38BE51EA.E8E1F822@iue.tuwien.ac.at>
Mark Hammond wrote:
> > > So maybe "Improve the interpreter command
> > > line behaviour" should be another item on
> > > the todo list.
> >
> > I think having a feature like Pythonwin's CTRL+UP and CTRL+DOWN
> > (with which you
> > can access the command history) here would help.
>
> hehe - Id love to take the credit, but I stole them from IDLE - isnt it
> Alt-N and Alt-P or something?
Indeed it is.
--
Markus
From guido@python.org Thu Mar 2 13:47:27 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 02 Mar 2000 08:47:27 -0500
Subject: [Idle-dev] Small patch to AutoExpand.py
In-Reply-To: Your message of "Thu, 02 Mar 2000 00:01:41 EST."
<000c01bf8404$65c35920$732d153f@tim>
References: <000c01bf8404$65c35920$732d153f@tim>
Message-ID: <200003021347.IAA16541@eric.cnri.reston.va.us>
> [Mark Hammond]
> > While using the auto-expand feature, it struck me that it really
> > should also match against builtin names.
> >
> > Eg, if I enter "Index" and select auto-complete, IndexError should
> > appear, even if it doesnt exist in the source file.
> >
> > Does anyone else agree?
[Tim]
> Guido notwithstanding , I agree. "Complete a name" is a single
> concept in my head, not helped by Emacs-like prissy distinctions attached to
> yet another batch of key bindings. The way to make this pleasant *and*
> useful is to (over time) increase a single function's context awareness.
>
> BTW, I've written word-completion pkgs for several editors that lacked the
> feature, and one of the most valuable things you can do for programmers is
> to search *other* open buffers for names too (e.g., picture editing a .cpp
> file where a heavily used .h file is open in another buffer). When it gets
> to this stage, it's also valuable to display a status msg giving the file
> name & line number of the currently-suggested completion.
Absolutely true -- Emacs' dabbrev-expand (Alt-/ for me) does this. It
also lets you cancel the search (it can take a while to search 200
buffers).
By the way, there's a different distinction possible here. Mark seems
to be fond of features like call-tips and attribute-tips that pop up
little yellow windows without asking. I've met at least one user who
turned off call-tips in IDLE, and I must say that it's a mixed
blessing for me. (Maybe it should disappear quicker?) The completion
feature is only invoked when the user hits a key (Alt-/ or
Control-space or tab or whatever).
Assuming we have a single context-sensitive completion, that you hit
repeatedly until the right suggestion shows up (like in Emacs). When
you exhaust the attributes of the object it thinks you are looking at,
should it continue to try other names it finds in the same buffer or
in other buffers that start with the same prefix? Example:
I'm looking at "x.a" and I hit Alt-/. It knows there's a global x and
it knows x has attributes 'argument' and 'alphabet', so it will
suggest these in some order. After exhausting the list, should it try
other a-words in the same buffer? This seems silly, but perhaps the
context is this:
class C:
argument = 1
alphabet = "abc"
anchor = "foo"
x = C()
x.a
^
Quite possibly I want to type "x.anchor = anchor"; but just as likely
I might want to display x.argument or x.alphabet...
In my design I would hit control-space to see the existing attributes,
and Alt-/ to expand from any nearby identifier.
Clearly an area where we could do some user testing...
--Guido van Rossum (home page: http://www.python.org/~guido/)
From guido@python.org Thu Mar 2 14:04:02 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 02 Mar 2000 09:04:02 -0500
Subject: [Idle-dev] Extends an events
In-Reply-To: Your message of "Thu, 02 Mar 2000 09:58:32 +0100."
References:
Message-ID: <200003021404.JAA16622@eric.cnri.reston.va.us>
> I thin over adding a "Recent files" list for the IDLE file menu.
> My first thought was to use extend.py but I dont know how I can capture
> the "Open event".
>
> Is this possible with extend.py ???
>
> If this is not already possible to capture the menu events without changeing
> the
> IDLE Source I think this should be added.
>
> Such a feature is very usefull for file locking or check in / check out
> mechanisms.
To add Recent files, you would have to modify the "open" command.
The menus are configurable by extensions, but capturing standard menus
is not possible yet. Can you suggest an architecture for that?
--Guido van Rossum (home page: http://www.python.org/~guido/)
From gritsch@iue.tuwien.ac.at Thu Mar 2 14:41:50 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Thu, 02 Mar 2000 15:41:50 +0100
Subject: [Idle-dev] Small patch to AutoExpand.py
References: <000c01bf8404$65c35920$732d153f@tim> <200003021347.IAA16541@eric.cnri.reston.va.us>
Message-ID: <38BE7DAD.FE43918E@iue.tuwien.ac.at>
Guido van Rossum wrote:
> > [Mark Hammond]
> > > While using the auto-expand feature, it struck me that it really
> > > should also match against builtin names.
> > >
> > > Eg, if I enter "Index" and select auto-complete, IndexError should
> > > appear, even if it doesnt exist in the source file.
> > >
> > > Does anyone else agree?
> [Guido]
> By the way, there's a different distinction possible here. Mark seems
> to be fond of features like call-tips and attribute-tips that pop up
> little yellow windows without asking.
I do too. Imagine you have an instance of a class which has, say about 30 set and
corresponding 30 get methods. If you want to go thru all this attributes by
pressing up to 60 times ALT-/ this would be annoying. In a attribute-tips pup up
I can scroll thru the various attributes with cursor or pg-up and pg-down keys
and can select on by typing RETURN or something.
> I've met at least one user who
> turned off call-tips in IDLE, and I must say that it's a mixed
> blessing for me. (Maybe it should disappear quicker?)
I think it's o.k. when there is an option to turn it on or off.
But I think Mark's idea was to include *builtin names* in a popup.
o.k. I will try to explain Forte4Java's completion and auto-completion features,
because this is a very professional looking IDE, and I think they have thought *a
lot* of how to improve the user-friendlyness.
Lets say I have already typed the following code:
class FooClass:
def barMethod(self):
print 'bar'
def bazMethod(self, text):
print text
myObject = FooClass()
now I type
myOb
and while having the cursor located after the b I press CTRL+SPC. Now a pup up is
shown with all the possible completions for myOb, in this case only 'myObject'
would be shown. By pressing enter the selected entry in the pup up window is
choosen and the pup up is closed. By pressing TAB myOb would be comleted as much
as possible, and the pup up stays.
Now I type a point:
myObject.
The pop up now shows all the properties of the object FooClass, and if FooClass
would be inherited from some other class, even the properties of the parent(s)
would be shown. Again I can select and choose on by pressing RETURN (the pop up
is closed), or I can complete as much as possible by pressing TAB (the pop up
remains).
The important thing is, that the pup up only pops up when I explicitly press
CTRL-SPC, or when I type a point after an object and wait some time. The pop up
can be closed at any time by pressing ESC.
And word completion (ALT+/ in Emacs) is available *separately* by another
key-combination. Word completion completes the word as much as possible, but
without showing a pop up window.
There is no difference between attribute-tip and call-tip. The arbument names are
shown together with the attributes. In the example above something like
myObject.
+-----------------+
| barMethod() |
| bazMethod(text) |
+-----------------+
I hope this clearifys some things ...
Kind regards,
Markus
--
|\/\/\/|
/------------------------------------------------------------------\ | |
| Markus GRITSCH | phone: +43 / 1 / 58801-36015 | | |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431 | | (o)(o)
| Technical University of Vienna | fax: +43 / 1 / 58801-36099 | C _)
| Gusshausstrasse 27-29 / E360 | email: gritsch@iue.tuwien.ac.at | | ,___|
| A-1040 Vienna / AUSTRIA | SMS: 436764973431@max.mail.at | | /
\------------------------------------------------------------------/ /____\
/ \
"Computers let you make more mistakes faster than any other invention in human
history, with the possible exception of handguns and tequila."
Mitch Radcliffe
From guido@python.org Thu Mar 2 15:00:36 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 02 Mar 2000 10:00:36 -0500
Subject: [Idle-dev] Small patch to AutoExpand.py
In-Reply-To: Your message of "Thu, 02 Mar 2000 15:41:50 +0100."
<38BE7DAD.FE43918E@iue.tuwien.ac.at>
References: <000c01bf8404$65c35920$732d153f@tim> <200003021347.IAA16541@eric.cnri.reston.va.us>
<38BE7DAD.FE43918E@iue.tuwien.ac.at>
Message-ID: <200003021500.KAA16953@eric.cnri.reston.va.us>
> > [Guido]
> > By the way, there's a different distinction possible here. Mark seems
> > to be fond of features like call-tips and attribute-tips that pop up
> > little yellow windows without asking.
[Markus Gritsch]
> I do too. Imagine you have an instance of a class which has, say
> about 30 set and corresponding 30 get methods. If you want to go
> thru all this attributes by pressing up to 60 times ALT-/ this would
> be annoying. In a attribute-tips pup up I can scroll thru the
> various attributes with cursor or pg-up and pg-down keys and can
> select on by typing RETURN or something.
What you would typically do is type a 2-3 letters and *then* hit
Alt-/.
...snip...
> and while having the cursor located after the b I press
> CTRL+SPC. Now a pup up is shown with all the possible completions
> for myOb, in this case only 'myObject' would be shown. By pressing
> enter the selected entry in the pup up window is choosen and the pup
> up is closed. By pressing TAB myOb would be comleted as much as
> possible, and the pup up stays.
It should be recomputed to show only the alternatives that are still
relevant.
> Now I type a point:
>
> myObject.
>
> The pop up now shows all the properties of the object FooClass, and if FooClass
> would be inherited from some other class, even the properties of the parent(s)
> would be shown. Again I can select and choose on by pressing RETURN (the pop up
> is closed), or I can complete as much as possible by pressing TAB (the pop up
> remains).
>
> The important thing is, that the pup up only pops up when I explicitly press
> CTRL-SPC, or when I type a point after an object and wait some time. The pop up
> can be closed at any time by pressing ESC.
Aha! The popup auto-pops *after a delay*. That's an important user
interface improvement. I think that that should also be implemented
for call-tips. If I start typing right away after the (, I apparently
know what the args are.
> And word completion (ALT+/ in Emacs) is available *separately* by another
> key-combination. Word completion completes the word as much as possible, but
> without showing a pop up window.
Aha. Just as I said. I suppose it also uses less context? Different
context? Word completion should work in comments, in string literals,
and in places where the UI doesn't know the type of variable you are
dealing with.
> There is no difference between attribute-tip and call-tip. The arbument names are
> shown together with the attributes. In the example above something like
>
> myObject.
> +-----------------+
> | barMethod() |
> | bazMethod(text) |
> +-----------------+
But you can show more a detailed call-tip when you have selected a
method (ours shows the first line of the doc string if available).
--Guido van Rossum (home page: http://www.python.org/~guido/)
From gritsch@iue.tuwien.ac.at Thu Mar 2 15:17:26 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Thu, 02 Mar 2000 16:17:26 +0100
Subject: [Idle-dev] Small patch to AutoExpand.py
References: <000c01bf8404$65c35920$732d153f@tim> <200003021347.IAA16541@eric.cnri.reston.va.us>
<38BE7DAD.FE43918E@iue.tuwien.ac.at> <200003021500.KAA16953@eric.cnri.reston.va.us>
Message-ID: <38BE8606.384AE79C@iue.tuwien.ac.at>
Guido van Rossum wrote:
> [Markus Gritsch]
> > I do too. Imagine you have an instance of a class which has, say
> > about 30 set and corresponding 30 get methods. If you want to go
> > thru all this attributes by pressing up to 60 times ALT-/ this would
> > be annoying. In a attribute-tips pup up I can scroll thru the
> > various attributes with cursor or pg-up and pg-down keys and can
> > select on by typing RETURN or something.
>
> What you would typically do is type a 2-3 letters and *then* hit
> Alt-/.
I agree. But if I don't know any attribute of the object, and I want to see
what it's
capable of, I would only type the object's name, and then I would like to see
maybe
*lots* of attributes in a pup up window instead of traveling thru them in an
emacs-like word-completion mode.
But as I agree too, these are two different things which should be available
separately, as I mentioned below.
> ...snip...
> > and while having the cursor located after the b I press
> > CTRL+SPC. Now a pup up is shown with all the possible completions
> > for myOb, in this case only 'myObject' would be shown. By pressing
> > enter the selected entry in the pup up window is choosen and the pup
> > up is closed. By pressing TAB myOb would be comleted as much as
> > possible, and the pup up stays.
>
> It should be recomputed to show only the alternatives that are still
> relevant.
Of course it should be (and already is in Forte4Java)
> > Now I type a point:
> >
> > myObject.
> >
> > The pop up now shows all the properties of the object FooClass, and if FooClass
> > would be inherited from some other class, even the properties of the parent(s)
> > would be shown. Again I can select and choose on by pressing RETURN (the pop up
> > is closed), or I can complete as much as possible by pressing TAB (the pop up
> > remains).
> >
> > The important thing is, that the pup up only pops up when I explicitly press
> > CTRL-SPC, or when I type a point after an object and wait some time. The pop up
> > can be closed at any time by pressing ESC.
>
> Aha! The popup auto-pops *after a delay*. That's an important user
> interface improvement. I think that that should also be implemented
> for call-tips. If I start typing right away after the (, I apparently
> know what the args are.
And the delay time which is needed should be a user-changeable option.
> > And word completion (ALT+/ in Emacs) is available *separately* by another
> > key-combination. Word completion completes the word as much as possible, but
> > without showing a pop up window.
>
> Aha. Just as I said. I suppose it also uses less context? Different
> context? Word completion should work in comments, in string literals,
> and in places where the UI doesn't know the type of variable you are
> dealing with.
I think this feature is almost the same as the word-completion feature of
emacs. The
context is limited to the current file.
> > There is no difference between attribute-tip and call-tip. The arbument names are
> > shown together with the attributes. In the example above something like
> >
> > myObject.
> > +-----------------+
> > | barMethod() |
> > | bazMethod(text) |
> > +-----------------+
>
> But you can show more a detailed call-tip when you have selected a
> method (ours shows the first line of the doc string if available).
Yes, in that way it would be fine to have this additional information
available. But
It would also be fine, if not only the method name, but also it's variable
names are
shown in the pup up window as shown in the example above.
Kindest regards,
Markus
--
|\/\/\/|
/------------------------------------------------------------------\ | |
| Markus GRITSCH | phone: +43 / 1 / 58801-36015 | | |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431 | | (o)(o)
| Technical University of Vienna | fax: +43 / 1 / 58801-36099 | C _)
| Gusshausstrasse 27-29 / E360 | email: gritsch@iue.tuwien.ac.at | | ,___|
| A-1040 Vienna / AUSTRIA | SMS: 436764973431@max.mail.at | | /
\------------------------------------------------------------------/ /____\
/ \
"Computers let you make more mistakes faster than any other invention in human
history, with the possible exception of handguns and tequila."
Mitch Radcliffe
From barmeier@BARMEIER.COM Thu Mar 2 16:12:54 2000
From: barmeier@BARMEIER.COM (Matthias Barmeier)
Date: Thu, 2 Mar 2000 17:12:54 +0100
Subject: AW: [Idle-dev] Extends an events
In-Reply-To: <200003021404.JAA16622@eric.cnri.reston.va.us>
Message-ID:
Hi,
What do you think about this:
Every menu item will register an a central "event manager". The event
manager will store the
menu items name like "File/Open..." as key in a dictionary. When registering
the calling extension
will transmit the callback for the default function to the event manager
too. The callback is stored
in an array attached to the dictionary.
The code is for reading only !! (not for running)
evtmgr={}
def menuRegisterCallback (itemName, defaultCallback, type=2): ## 2=default,
## 1=call before default, 3=call after default
if not evtmgr.has_key(itemName):
evtmgr[itemName]=[]
evtmgr[itemName].append((defaultCallback,type))
evtmgr.sort(... for type ...)
When a menu item is selected a menu "driver function" is called that makes a
lookup in the evtmgr dictionary
and calls all callbacks (ordered by type) that are stored there in the
dictionary.
def menuDriveEvent (itemName):
results={}
for calls,type in evtmgr[itemName]:
## any callback can have some results the
## should be passed and manipulated by the callbacks in the
## chain.
results=calls (itemName,results)
Usage?
Could happen like this:
To add the standard functionality :
def openfile (itemName, params):
if !params.has_key("defaultdir"):
... use standard directory to open file dialog ...
else:
... use params["defaultdir"] ...
... after selectting a file ...
params["filename"]=the_filename
return (params)
menuRegisterCallback ("File/Open...", openfile, 2)
To intercept:
def maintainRecentlist (itemName, params):
addFileToRecentList (itemName)
return (params) ## do nothing with the params
menuRegisterCallback ("File/Open...", maintainRecentList, 3)
The Tcl/Tk menubutton callback must be redirected to the EventDriver but I
think
this could work. (after the hard work is done of course ;-) )
This is from scratch. My english is not good enough but I hope the code
will help to understand what I want to say.
What do you think does this make any sense to you ??
/*
Dipl.-Inform. Matthias Barmeier Tel: +49 (0)30 79 70 72 87
Büro für Softwareentwicklung Fax +49 (0)30 79 70 72 88
Grunewaldstr. 18 Email: barmeier@barmeier.com
12165 Berlin WWW:
*/
> -----Ursprüngliche Nachricht-----
> Von: guido@CNRI.Reston.VA.US [mailto:guido@CNRI.Reston.VA.US]Im Auftrag
> von Guido van Rossum
> Gesendet: Donnerstag, 2. März 2000 15:04
> An: Matthias Barmeier
> Cc: idle-dev@python.org
> Betreff: Re: [Idle-dev] Extends an events
>
>
> > I thin over adding a "Recent files" list for the IDLE file menu.
> > My first thought was to use extend.py but I dont know how I can capture
> > the "Open event".
> >
> > Is this possible with extend.py ???
> >
> > If this is not already possible to capture the menu events
> without changeing
> > the
> > IDLE Source I think this should be added.
> >
> > Such a feature is very usefull for file locking or check in / check out
> > mechanisms.
>
> To add Recent files, you would have to modify the "open" command.
>
> The menus are configurable by extensions, but capturing standard menus
> is not possible yet. Can you suggest an architecture for that?
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
From guido@python.org Thu Mar 2 16:17:56 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 02 Mar 2000 11:17:56 -0500
Subject: AW: [Idle-dev] Extends an events
In-Reply-To: Your message of "Thu, 02 Mar 2000 17:12:54 +0100."
References:
Message-ID: <200003021617.LAA17217@eric.cnri.reston.va.us>
[Matthias Barmeier]
> Every menu item will register an a central "event manager". The
> event manager will store the menu items name like "File/Open..." as
> key in a dictionary. When registering the calling extension will
> transmit the callback for the default function to the event manager
> too. The callback is stored in an array attached to the dictionary.
[...code stripped...]
I don't understand why you need the type argument. And why you need
to pass results between the handlers?
Tcl already has an event/binding management architecture; see the
bindtags command
(http://dev.scriptics.com/man/tcl8.3/TkCmd/bindtags.htm).
I would like to build on that if possible.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From barmeier@BARMEIER.COM Thu Mar 2 16:33:38 2000
From: barmeier@BARMEIER.COM (Matthias Barmeier)
Date: Thu, 2 Mar 2000 17:33:38 +0100
Subject: [Idle-dev] Extends an events
In-Reply-To: <200003021617.LAA17217@eric.cnri.reston.va.us>
Message-ID:
Hi,
[...code stripped...]
>
> I don't understand why you need the type argument.
I think it could be possible that "someone" want to be called BEFORE the
menus
default function is executed.
Other functions like the "recent files" require that the standard function
was executed.
By simply sorting the array all functions of type 1 will be called before
type 2 and type 3 functions
are called after type 2 functions.
> And why you need
> to pass results between the handlers?
When a function is executed after the standard function the "after function"
needs access to the
results. Instead of accessing some values like the filename directly I think
it should be better
to decouple (right word ?) the callbacks as much as possible. If someone
adds a value nobody needs
nothing happens. Everbody can examine the params dict to see whats in
without knowing something
about the other extensions that could be attached to the same menu.
>
> Tcl already has an event/binding management architecture; see the
> bindtags command
> (http://dev.scriptics.com/man/tcl8.3/TkCmd/bindtags.htm).
>
> I would like to build on that if possible.
Oh, I dont know that the manager is accessible. I will take a look and will
try to make it fit
if possible.
From mhammond@skippinet.com.au Thu Mar 2 21:56:16 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 3 Mar 2000 08:56:16 +1100
Subject: [Idle-dev] Small patch to AutoExpand.py
In-Reply-To: <38BE7DAD.FE43918E@iue.tuwien.ac.at>
Message-ID:
> > [Guido]
> > By the way, there's a different distinction possible here. Mark seems
> > to be fond of features like call-tips and attribute-tips that pop up
> > little yellow windows without asking.
>
> I do too.
:-)
Some person with a couple of hours should take this on for IDLE. It would
not be hard to take the existing Tk "calltip" code and convert it to a
pop-up listbox for attribute expansion. Pythonwin already has code to find
the entries for the listbox, and in such a way that making this work for Tk
should not be hard.
I mentioned this to Guido before, and he seemed generally interested but
simply lacking time for these sorts of features.
So any volunteers?
Mark.
From Albert.Brandl@edvg.co.at Fri Mar 3 08:25:21 2000
From: Albert.Brandl@edvg.co.at (Albert Brandl)
Date: Fri, 3 Mar 2000 09:25:21 +0100
Subject: [Idle-dev] IDLE interpreter window
Message-ID:
Hi!
> hehe - Id love to take the credit, but I stole them from IDLE - isnt it
> Alt-N and Alt-P or something?
Thanks for the advice. But the presence of a work-around for accessing
the history does not hide the fact that the *Python Shell* looks like
a shell but does not behave like one. IMHO it should try to resemble
the usual shell behaviour as closely as possible (Gerrit's idea of
introducing "modes" points to this direction). I think that everyone who
uses shells expects a certain behaviour when using the *Python Shell*.
And I _don't_ think many people expect the cursor to go up one line when
pressing the Up-Arrow ;-)
Another example: It's possible to remove the ">>>" by using the backspace
key. Ever done that at a bash / csh / tcsh prompt? ;-) When it first
happened to me, I entered the missing ">" in order to re-establish the
"correct" look of the window. I was _quite_ astonished to get a syntax
error when executing the next command!
I think the semantics of the arrow keys and backspace are essential if
the *Python Shell* window is to be widely accepted.
Best regards,
Albert
From jeremy@cnri.reston.va.us Fri Mar 3 23:18:56 2000
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Fri, 3 Mar 2000 18:18:56 -0500 (EST)
Subject: [Idle-dev] config files
Message-ID: <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us>
I just checked in a simple configuration management framework for
IDLE. It gets configurable options from one or more config files
instead of from constants in the code itself.
Note that it depends on the current version of the ConfigParser
module. You'll need to get that from the CVS tree when you get the
new IDLE.
Question for Windows users: What is a natural place for a per-users
config file? On Unix, I'm looking in "%s/.idle" % os.environ['HOME'].
HOME is defined on Guido's Windows box, but I don't know that I can
depend on it.
Jeremy
From mhammond@skippinet.com.au Sat Mar 4 02:19:55 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Sat, 4 Mar 2000 13:19:55 +1100
Subject: [Idle-dev] config files
In-Reply-To: <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us>
Message-ID:
> Question for Windows users: What is a natural place for a per-users
> config file? On Unix, I'm looking in "%s/.idle" % os.environ['HOME'].
> HOME is defined on Guido's Windows box, but I don't know that I can
> depend on it.
I would suggest simply placing it in the Python directory - from
sys.executable. Who ever complains that this is not sufficient gets to fix
it ;-)
Mark.
From neilh@scintilla.org Sat Mar 4 02:25:53 2000
From: neilh@scintilla.org (Neil Hodgson)
Date: Sat, 4 Mar 2000 13:25:53 +1100
Subject: Fw: [Idle-dev] config files
Message-ID: <03d501bf8581$02d2ad60$01646464@computer>
> > Question for Windows users: What is a natural place for a per-users
> > config file? On Unix, I'm looking in "%s/.idle" % os.environ['HOME'].
> > HOME is defined on Guido's Windows box, but I don't know that I can
> > depend on it.
>
> The preferred place these (W2K) days is
>
> [CSIDL_APPDATA]\[User]\Application Data\[Company Name]\[Product Name]
>
> The string value of CSIDL_APPDATA is found by calling ShGetFolderPath.
>
> Putting files here ensures they handle 'roaming' correctly and follow
the
> user around to any machine they work on.
>
> A high level article that talks about this is:
> http://www.microsoft.com/MSJ/0899/logo/logotop.htm
> For more specifics there is a specification at:
> http://msdn.microsoft.com/certification/appspec.asp
>
> For earlier versions of Windows, there is a redistributable
SHFOLDER.DLL
> that will do the right thing.
>
> Neil
From tim_one@email.msn.com Sat Mar 4 02:48:20 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 3 Mar 2000 21:48:20 -0500
Subject: [Idle-dev] config files
In-Reply-To:
Message-ID: <000101bf8584$19c85580$c6a0143f@tim>
[Jeremy Hylton]
> Question for Windows users: What is a natural place for a per-users
> config file? On Unix, I'm looking in "%s/.idle" % os.environ['HOME'].
> HOME is defined on Guido's Windows box, but I don't know that I can
> depend on it.
You cannot. Envars are to be avoided like the plague (or like Perl,
whichever you fear more, and if you believe there's a difference )
under Windows.
[Mark Hammond]
> I would suggest simply placing it in the Python directory - from
> sys.executable. Who ever complains that this is not sufficient
> gets to fix it ;-)
Agree with Mark. Name it idle.ini, for minimal Windows surprise and maximal
Windows portability.
or-".idle"-to-maximize-surprise-and-minimize-portability-ly y'rs - tim
From tim_one@email.msn.com Sat Mar 4 07:26:42 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 4 Mar 2000 02:26:42 -0500
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To:
Message-ID: <000001bf85aa$fd6432c0$b02d153f@tim>
[Albert Brandl, misses shell history features in IDLE, likes them in
PythonWin]
[it's pointed out that IDLE has them too]
[Mark Hammond, PythonWin's dad]
> hehe - Id love to take the credit, but I stole them from IDLE - isnt it
> Alt-N and Alt-P or something?
[Albert Brandl
> Thanks for the advice. But the presence of a work-around for accessing
> the history does not hide the fact that the *Python Shell* looks like
> a shell but does not behave like one. IMHO it should try to resemble
> the usual shell behaviour as closely as possible
What is "usual shell behaviour"? There are dozens of shells out there.
You're putting way too much weight on the word "shell", methinks: the
Python Shell is really an editor window, that happens to have the added
feature of being able to execute Python in interactive mode. Do Help->Help
to read about the features "the shell" window has that IDLE's other editing
Windows don't have; it also has all the features of an IDLE editing window.
> (Gerrit's idea of introducing "modes" points to this direction). I think
> that everyone who uses shells expects a certain behaviour when using
> the *Python Shell*. And I _don't_ think many people expect the cursor
> to go up one line when pressing the Up-Arrow ;-)
If they think of it as an editor window instead (which it is, by design and
by implementation), that behavior for Up-Arrow is certainly expected.
> Another example: It's possible to remove the ">>>" by using the backspace
> key. Ever done that at a bash / csh / tcsh prompt? ;-)
No, and that's one reason the IDLE "shell" is much better. Not kidding! I
use it heavily, and the ability to edit the shell window in arbitrary ways
is *great* for saving the important parts of an interactive session.
> ...
> I think the semantics of the arrow keys and backspace are essential if
> the *Python Shell* window is to be widely accepted.
Too late: it's already widely accepted <0.5 wink>.
if-you-want-an-os-shell-use-an-os-shell-or-rebind-all-your-idle-
keys-to-pretend-it's-something-it's-not-ly y'rs - tim
From gerrit@nl.linux.org Sat Mar 4 07:36:43 2000
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Sat, 4 Mar 2000 08:36:43 +0100
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To: <000001bf85aa$fd6432c0$b02d153f@tim>; from tim_one@email.msn.com on Sat, Mar 04, 2000 at 02:26:42AM -0500
References: <000001bf85aa$fd6432c0$b02d153f@tim>
Message-ID: <20000304083643.A30485@nl.linux.org>
> [Albert Brandl]
> > IMHO it should try to resemble the usual shell behaviour as closely
> > as possible
>
> What is "usual shell behaviour"?
Being extremely configurable with key bindings and having 'modes'. As
said earlier, I like to have 'set -o vi' behaviour, others may like
other key behaviour. I don't like the Idle interactive interpreter
because something like 'set -o vi' is not possible (yet, I hope).
regards,
Gerrit.
--
Plies korekt enie bet ingglisj joe encauntur in mai imil mesusj!
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----
From barmeier@BARMEIER.COM Sun Mar 5 10:22:31 2000
From: barmeier@BARMEIER.COM (Matthias Barmeier)
Date: Sun, 5 Mar 2000 11:22:31 +0100
Subject: AW: AW: [Idle-dev] Extends an events
In-Reply-To: <200003021617.LAA17217@eric.cnri.reston.va.us>
Message-ID:
Hi,
I have checked the Tcl/Tk bind and bindings. But as I can see parameter
passing
is impossible when using this approach.
When I find an hour or two in the next week I will try to make a suggestion
in
form of a modified EditorWindow.py.
What do you think ?
Ciao
Matthias Barmeier
/*
Dipl.-Inform. Matthias Barmeier Tel: +49 (0)30 79 70 72 87
Büro für Softwareentwicklung Fax +49 (0)30 79 70 72 88
Grunewaldstr. 18 Email: barmeier@barmeier.com
12165 Berlin WWW:
*/
From guido@python.org Sun Mar 5 12:27:32 2000
From: guido@python.org (Guido van Rossum)
Date: Sun, 05 Mar 2000 07:27:32 -0500
Subject: AW: AW: [Idle-dev] Extends an events
In-Reply-To: Your message of "Sun, 05 Mar 2000 11:22:31 +0100."
References:
Message-ID: <200003051227.HAA05425@eric.cnri.reston.va.us>
> I have checked the Tcl/Tk bind and bindings. But as I can see
> parameter passing is impossible when using this approach.
In the rare cases where you need to pass parameters around, you can
place them on the EditorWindow (or whatever) instance. This can
simply be part of the specs of a particular binding (e.g. open).
> When I find an hour or two in the next week I will try to make a
> suggestion in form of a modified EditorWindow.py.
Great!
--Guido van Rossum (home page: http://www.python.org/~guido/)
From KRodgers@ryanaero.com Sun Mar 5 17:52:09 2000
From: KRodgers@ryanaero.com (Rodgers, Kevin)
Date: Sun, 5 Mar 2000 09:52:09 -0800
Subject: [Idle-dev] IDLE interpreter window
Message-ID: <0D8C1A50C283D311ABB800508B612E5354B3C0@ryanaero.com>
The rest of Tim's message went on to show why thinking of IDLE's "shell"
window as something akin to a Unix "shell" is too limiting. Your quote here
is kinda out of context.
Maybe the IDLE shell window should be called the "interactive" window or
something, to prep people that it's not just a Unix-style shell . . .
--
Kevin Rodgers Northrop Grumman Ryan Aeronautical krodgers@ryanaero.com
"Snakes. Why did it have to be snakes?!" -- Indiana Jones
> -----Original Message-----
> From: Gerrit Holl [SMTP:gerrit@nl.linux.org]
> Sent: Friday, March 03, 2000 11:37 PM
> To: Tim Peters
> Cc: idle-dev@python.org
> Subject: Re: Re: [Idle-dev] IDLE interpreter window
>
>
> > [Albert Brandl]
> > > IMHO it should try to resemble the usual shell behaviour as closely
> > > as possible
> >
> > What is "usual shell behaviour"?
>
>
> Being extremely configurable with key bindings and having 'modes'. As
> said earlier, I like to have 'set -o vi' behaviour, others may like
> other key behaviour. I don't like the Idle interactive interpreter
> because something like 'set -o vi' is not possible (yet, I hope).
>
> regards,
> Gerrit.
>
> --
> Plies korekt enie bet ingglisj joe encauntur in mai imil mesusj!
> -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
> Version: 3.12
> GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V
> PS+ PE?
> Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
> -----END GEEK CODE BLOCK-----
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev@python.org
> http://www.python.org/mailman/listinfo/idle-dev
From dscherer@cmu.edu Sun Mar 5 20:27:02 2000
From: dscherer@cmu.edu (David Scherer)
Date: Sun, 5 Mar 2000 15:27:02 -0500
Subject: [Idle-dev] What we need, and how we can help
Message-ID:
Hi, all.
Let me start with a brief introduction. I'm an undergraduate at Carnegie
Mellon University, and I'm working with several other students and faculty
members to develop a visualization library for Python and deploy it in the
physics curriculum here. Two of my collaborators, Bruce Sherwood and Ruth
Chabay, currently teach a two-semester introductory physics sequence called
"Matter and Interactions," in which students write graphical simulations of
physical processes in a language called cT. We think that a Python-based
environment could be both easier to use and more powerful for this purpose.
The goal is to teach physics, not programming. At present, only two days
out of the year are devoted to teaching students (a large minority of whom
have never programmed before) to use the language and environment. This
sets an extremely high standard for the ease of use of every component of
the system.
We plan to put a significant amount of effort into bringing a development
environment to that level. If the evolution of IDLE can dovetail with our
needs, as we believe it can, then we will be happy to contribute to IDLE.
If not, we would still like to share as much concept and code as possible.
Here's what we think we need. Some of this fits in with what Guido has
already said about the future of IDLE, and some of it reflects a difference
in focus. We are, of course, content to have features in our environment
that are unimportant to us, so long as they can be configured to be
unobtrusive.
1. The IDE *must* be stable in the face of any correct or incorrect user
program (e.g. infinite loops, access to Tcl/Tk and the window system, etc.).
The user program also needs to start in a fresh interpreter so that its
behavior cannot be affected by previous runs. Given the complexities of
shared access to libraries, this almost certainly means a separate OS
process for the user program. We have prototyped a simple IDLE extension
that runs programs this way, but it does not yet permit adequate error
reporting or debugging.
2. Interactive mode is not very important to us, at least for now. As
attractive as the instant feedback it offers seems, there are serious
problems with it for our purposes. For example:
- It is impossible to reverse changes. When a student makes a mistake in
an editor environment, pressing "undo" a few times and re-running the
program suffices to correct it. In interactive mode there is no obvious way
to reverse actions which had side effects on the environment. At present
there isn't even an easy way to start over.
- It is hard to work with loops. Many of the programs our students will be
writing are simulations in which the bulk of the code is inside a single,
large loop. The user must type in the entire loop at once, which is
difficult and sacrifices all the advantages of interactive mode.
3. Given that students will be writing all of their code in the editor
rather than the interactive window, and that we wish to encourage a highly
iterative development process, it is important that the process of running
programs from the editor be as streamlined as possible. Ideally, editing a
program should be as subjectively responsive as interactive mode. One
keystroke to execute a program is better than two or three. Program output
needs to be organized on the screen so that students don't need to change
focus or play whack-a-mole with output windows. It needs to be easy to
terminate a program.
4. We do not expect to make much use of the debugger. Physics simulations
are difficult to debug by single-stepping, because many steps are often
necessary before errors become apparent. If the debugger cannot provide a
very large benefit to students, we don't have time to teach it. Instead, we
plan to add inspection capabilities to our visualization library.
5. Error reporting is *very* important.
- Syntax errors and exceptions should be presented in the same way even
though they are reported through different mechanisms.
- Highlighting the offending source code is a must. The right code, or a
superset, always needs to be highlighted. Something as simple as the
following can really confuse a novice:
line((1,2),(3,4) # error is here
line((1,2),(3,4)) # but is reported on this line
- Tracebacks should not by default extend into "system" modules, even if
those modules are implemented in Python. Exactly how the IDE decides what
is a system module depends on whether and how it supports projects.
Anything that is open in an editor window or part of the current project is
not a system module.
- Error messages need to be as specific and clear as possible. Lots of the
messages currently returned by Python and its libraries could stand to be
rewritten with the novice programmer in mind. More precise identification
of syntactical errors would also be very helpful - "Missing )" is much
better than just "Syntax error".
6. Cross-platform support is important. Windows, Unix, and Macintosh all
need to be supported. The latter is obviously most difficult. IDLE can
easily be made to start on the Mac, but there are serious stability problems
with Tkinter. We are investigating those, but any advice would be
appreciated.
7. We plan to distribute a single installer to students in the course (and
to anyone else who is interested), which will include Python, our
visualization library, an IDE that suits our needs, and all the libraries
such as Numeric and Tcl/Tk which the first three components require.
- We will make synchronized releases for all platforms if possible.
- We have developed a prototype Windows installer which differs from the
standard Python installer in several important ways, including integrating
an *unshared* copy of Tcl/Tk. We believe it will reduce the number of
installation problems significantly.
- If Python and IDLE are adopted in education on any scale, many other
people will want to roll their own distributions for similar reasons. The
process could be streamlined considerably - for example, by making the
source for existing installers available. Another issue which bears
consideration is how multiple distributions should coexist on the same
machine.
Dave Scherer
From Albert.Brandl@edvg.co.at Mon Mar 6 10:01:03 2000
From: Albert.Brandl@edvg.co.at (Albert Brandl)
Date: Mon, 6 Mar 2000 11:01:03 +0100
Subject: [Idle-dev] IDLE interpreter window
Message-ID:
>What is "usual shell behaviour"? There are dozens of shells out there.
My fault - sorry. Of cause there are dozens of shells out there. What I was
talking about was the "shell metaphor":
Each shell I know (not too many, I confess) uses the concept of a prompt.
Interaction with the shell occurs at the prompt. You enter a command,
press Return and watch what happens. The shell processes the command,
presents the results (if any) and shows a new prompt line.
The cursor has very limited abilities to move:
- left and right, bounded by the prompt and the end of the issued command,
respectively
- up and down scrolls through the history
>If they think of it as an editor window instead (which it is, by design and
>by implementation), that behavior for Up-Arrow is certainly expected.
Frankly, I don't think that "Editor window" is a good metaphor for the
*Python Shell*. The main purpose is to execute commands issued by the
user - something usually accomplished with a _shell_, not an editor.
>[...] that's one reason the IDLE "shell" is much better. Not kidding! I
>use it heavily, and the ability to edit the shell window in arbitrary ways
>is *great* for saving the important parts of an interactive session.
If you copy the relevant contents of the shell window with the mouse, paste
it into an editor window and edit it _there_, you get the same effect (except
that you do not have to be careful not to press the "return" key, since
it moves the cursor to the prompt). So where's the benefit?
Best regards,
Albert
From aa8vb@yahoo.com Mon Mar 6 13:07:26 2000
From: aa8vb@yahoo.com (Randall Hopper)
Date: Mon, 6 Mar 2000 08:07:26 -0500
Subject: [Idle-dev] Re: config files
In-Reply-To: <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us>
References: <000101bf8584$19c85580$c6a0143f@tim> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us>
Message-ID: <20000306080726.A2561@vislab.epa.gov>
Jeremy Hylton:
|I just checked in a simple configuration management framework for IDLE.
|It gets configurable options from one or more config files instead of
|from constants in the code itself.
...
As IDLE is a Tkinter app, why not use the Tk mechanism for specifying
resources? It's already generalized for cross-platform support. On MSWin,
the resources go in the tk.tcl file (according to Brent Welch in his Tcl/Tk
book). On UNIX, that translates into .Xdefaults (standard X resource cfg
that newbies quickly learn). The difference is abstracted by Tk and the
app code is the same.
Alternatively, Tkinter supports reading startup "profile" code (written in
Python) for Tkinter apps. The file loaded is based on the appname and
classname passed to Tk() -- see Tkinter.py::readprofile() for details.
Tim Peters:
|[Mark Hammond]
|> I would suggest simply placing it in the Python directory - from
|> sys.executable. Who ever complains that this is not sufficient
|> gets to fix it ;-)
|
|Agree with Mark. Name it idle.ini, for minimal Windows surprise and maximal
|Windows portability.
Please don't do that. UNIX users hate that. I wouldn't ask that you call
it ".idlerc" on MSWindows platforms, for maximal UNIX portability. :-)
Let's do what make sense on each OS, and if possible use an API that
already supports each platform's conventions transparently (.ini on
Windows, ~/. on UNIX).
--
Randall Hopper
aa8vb@yahoo.com
A recent thread on this topic in c.l.py:
http://www.deja.com/=dnc/[ST_rn=ps]/viewthread.xp?search=thread&recnum=%3c20000225073335.A3192031@vislab.epa.gov%3e%231/1&AN=589831804&svcclass=dnserver&frpage=getdoc.xp
From guido@python.org Mon Mar 6 13:26:47 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 06 Mar 2000 08:26:47 -0500
Subject: [Idle-dev] Re: config files
In-Reply-To: Your message of "Mon, 06 Mar 2000 08:07:26 EST."
<20000306080726.A2561@vislab.epa.gov>
References: <000101bf8584$19c85580$c6a0143f@tim> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us>
<20000306080726.A2561@vislab.epa.gov>
Message-ID: <200003061326.IAA09512@eric.cnri.reston.va.us>
[Randall Hopper]
> As IDLE is a Tkinter app, why not use the Tk mechanism for specifying
> resources? It's already generalized for cross-platform support. On MSWin,
> the resources go in the tk.tcl file (according to Brent Welch in his Tcl/Tk
> book). On UNIX, that translates into .Xdefaults (standard X resource cfg
> that newbies quickly learn). The difference is abstracted by Tk and the
> app code is the same.
.Xdefaults quickly learnable by newbies? You've got to be kidding. I
am *stil* struggling with .Xdefaults. :-)
The real reason for going with our own config file syntax and location
is that we want to migrate to a system where the user can change the
configuration through a Preferences dialog. Note that on Windows, no
user expects to be editing a text file with configuration information
-- they expect to find a Preferences or Options dialog in one of the
app's menus.
> Alternatively, Tkinter supports reading startup "profile" code (written in
> Python) for Tkinter apps. The file loaded is based on the appname and
> classname passed to Tk() -- see Tkinter.py::readprofile() for details.
We considered this too -- and decided that the Python syntax gives too
much freedom for mistakes, and besides that we won't need it once we
have our preferences dialog.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From mhammond@skippinet.com.au Mon Mar 6 13:30:26 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Tue, 7 Mar 2000 00:30:26 +1100
Subject: [Idle-dev] Re: config files
In-Reply-To: <20000306080726.A2561@vislab.epa.gov>
Message-ID:
[Randal writes]
> Tim Peters:
> |[Mark Hammond]
> |> I would suggest simply placing it in the Python directory - from
> |> sys.executable. Who ever complains that this is not sufficient
> |> gets to fix it ;-)
> |
> |Agree with Mark. Name it idle.ini, for minimal Windows
> |surprise and maximal
> |Windows portability.
>
> Please don't do that. UNIX users hate that. I wouldn't ask that you call
> it ".idlerc" on MSWindows platforms, for maximal UNIX portability. :-)
Fear not - you are agreeing with us - you quoted out of context
(probably because the context was lost in the article you replied to) but
the question was specifically addressing only Windows - it was already
agreed Unix would follow local conventions (if only people could decide what
they were :-)
Mark.
From aa8vb@yahoo.com Mon Mar 6 14:26:54 2000
From: aa8vb@yahoo.com (Randall Hopper)
Date: Mon, 6 Mar 2000 09:26:54 -0500
Subject: [Idle-dev] Re: Re: config files
In-Reply-To: <200003061326.IAA09512@eric.cnri.reston.va.us>
References: <20000306080726.A2561@vislab.epa.gov> <000101bf8584$19c85580$c6a0143f@tim> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us> <20000306080726.A2561@vislab.epa.gov> <200003061326.IAA09512@eric.cnri.reston.va.us>
Message-ID: <20000306092654.A3640@vislab.epa.gov>
Guido van Rossum:
|The real reason for going with our own config file syntax and location
|is that we want to migrate to a system where the user can change the
|configuration through a Preferences dialog.
Sounds good. That would be more convenient.
|> Alternatively, Tkinter supports reading startup "profile" code (written in
|> Python) for Tkinter apps. The file loaded is based on the appname and
|> classname passed to Tk() -- see Tkinter.py::readprofile() for details.
|
|We considered this too -- and decided that the Python syntax gives too
|much freedom for mistakes, and besides that we won't need it once we
|have our preferences dialog.
Good point. As long as the config file remains editable even after the
Preferences editor is in place, I like the idea.
Mark Hammond:
|Fear not - you are agreeing with us - you quoted out of context
|(probably because the context was lost in the article you replied to) but
|the question was specifically addressing only Windows - it was already
|agreed Unix would follow local conventions (if only people could decide what
|they were :-)
Sorry about that. I'm glad to hear it was just my misunderstanding.
Jeremy's UNIX scheme was included the text Tim replied to, and I
misinferred that both platforms were being discussed.
--
Randall Hopper
aa8vb@yahoo.com
From Fredrik Lundh"
Message-ID: <000f01bf877c$8a6a9b00$34aab5d4@hagrid>
Albert Brandl wrote:
> Each shell I know (not too many, I confess) uses the concept of a =
prompt.
> Interaction with the shell occurs at the prompt. You enter a command,
> press Return and watch what happens. The shell processes the command,
> presents the results (if any) and shows a new prompt line.
otoh, every editor-based shell window I know (emacs,
epsilon, etc) work exactly like the one in IDLE.
> Frankly, I don't think that "Editor window" is a good metaphor for the
> *Python Shell*. The main purpose is to execute commands issued by the
> user - something usually accomplished with a _shell_, not an editor
maybe you should look outside the box?
From guido@python.org Mon Mar 6 15:19:44 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 06 Mar 2000 10:19:44 -0500
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To: Your message of "Mon, 06 Mar 2000 15:59:10 +0100."
<000f01bf877c$8a6a9b00$34aab5d4@hagrid>
References:
<000f01bf877c$8a6a9b00$34aab5d4@hagrid>
Message-ID: <200003061519.KAA09964@eric.cnri.reston.va.us>
> Albert Brandl wrote:
> > Each shell I know (not too many, I confess) uses the concept of a prompt.
> > Interaction with the shell occurs at the prompt. You enter a command,
> > press Return and watch what happens. The shell processes the command,
> > presents the results (if any) and shows a new prompt line.
[Fredrik]
> otoh, every editor-based shell window I know (emacs,
> epsilon, etc) work exactly like the one in IDLE.
>
> > Frankly, I don't think that "Editor window" is a good metaphor for the
> > *Python Shell*. The main purpose is to execute commands issued by the
> > user - something usually accomplished with a _shell_, not an editor
>
> maybe you should look outside the box?
In Albert's defense, I've often wished that a click in the PyShell
window would move the cursor to the command line, and also that typing
would automatically go into the command line.
Albert is probably an example of a typical newbie who's seen xterms
and DOS windows only, both of which have this interface (Emacs is
definitely not for newbies :-).
As long as there's a way to select a region in the shell output and
copy it using normal copy+paste commands, I think the needs of most
users are met -- I've often confused myself by editing a previously
executed command in place rather than copying it to the command line
or using the history commands.
Maybe a fully editable PyShell window should be an option for advanced
users.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From guido@python.org Mon Mar 6 15:30:08 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 06 Mar 2000 10:30:08 -0500
Subject: [Idle-dev] Setting the X resource options for IDLE windows
In-Reply-To: Your message of "Mon, 06 Mar 2000 08:07:26 EST."
<20000306080726.A2561@vislab.epa.gov>
References: <000101bf8584$19c85580$c6a0143f@tim> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us> <14528.18528.548883.426679@bitdiddle.cnri.reston.va.us>
<20000306080726.A2561@vislab.epa.gov>
Message-ID: <200003061530.KAA09985@eric.cnri.reston.va.us>
Randall Hopper has asked me to make sure that IDLE's windows have
reasonable names as seen by the X server and other X clients
(especially window managers), so that options can be set reasonably.
I've run into a few snags.
It's easy enough to set the name for the root Tk() window: use
root = Tk(className="Idle")
This will set the X11 proprerty WM_CLASS to ("idle", "Idle") when seen
through xprop, and WM_NAME to "idle".
But, the root is immediately withdrawn; all EditorWindows use
Toplevel(). To set the WM_CLASS property on these, I can use
win = Toplevel(class_="Idle")
This sets WM_CLASS to "123456", "Idle". In other words, the class is
indeed Idle but the instance is the randomly chosen widget name. If I
use
win = Toplevel(class_="Idle", name="idle")
I can only create one Toplevel, because "name" is now used as the Tk
widget name (".idle") and you can't have two widgets with the same
name.
I notice that the WM_NAME property is "idle" (same as the instance
part of WM_CLASS).
I have no idea which property window managers use to configure icons
etc. for windows (I'm not a very sophisticated X user and I'd like to
keep it that way :-).
Suggestions?
Randall also suggested that (as a fallback) the title and icon names
could be set to "idle: ...". I have no problem with this, but I'm not
sure if it's enough...
Feedback?
--Guido van Rossum (home page: http://www.python.org/~guido/)
From Fredrik Lundh" <000f01bf877c$8a6a9b00$34aab5d4@hagrid> <200003061519.KAA09964@eric.cnri.reston.va.us>
Message-ID: <00ac01bf8782$49a34bc0$34aab5d4@hagrid>
Guido wrote:
> As long as there's a way to select a region in the shell output and
> copy it using normal copy+paste commands, I think the needs of most
> users are met -- I've often confused myself by editing a previously
> executed command in place rather than copying it to the command line
> or using the history commands.
>=20
> Maybe a fully editable PyShell window should be an option for advanced
> users.
hey, now you're *thinking* outside the box ;-)
(fwiw, pythonworks won't have an 'interactive shell', at
least not in 1.0. instead, we're going for an improved 'run
untitled script' function. also see David Scherer's post).
From Moshe Zadka Mon Mar 6 17:40:51 2000
From: Moshe Zadka (Moshe Zadka)
Date: Mon, 6 Mar 2000 19:40:51 +0200 (IST)
Subject: [Idle-dev] Setting the X resource options for IDLE windows
In-Reply-To: <200003061530.KAA09985@eric.cnri.reston.va.us>
Message-ID:
On Mon, 6 Mar 2000, Guido van Rossum wrote:
> But, the root is immediately withdrawn; all EditorWindows use
> Toplevel().To set the WM_CLASS property on these, I can use
>
> win = Toplevel(class_="Idle")
>
> This sets WM_CLASS to "123456", "Idle".In other words, the class is
> indeed Idle but the instance is the randomly chosen widget name.
I think most window manager option are by class. AFAIK, "Class" is for
all windows of an application, while "Instance" should be different
for different types of toplevel.
(E.g., editor windows vs. pyshell windows)
Doesn't Tk allow you raw access to the class and instance names?
--
Moshe Zadka .
http://www.oreilly.com/news/prescod_0300.html
From Albert.Brandl@edvg.co.at Tue Mar 7 12:24:04 2000
From: Albert.Brandl@edvg.co.at (Albert Brandl)
Date: Tue, 7 Mar 2000 13:24:04 +0100
Subject: [Idle-dev] IDLE interpreter window
Message-ID:
>otoh, every editor-based shell window I know (emacs,
>epsilon, etc) work exactly like the one in IDLE.
I didn't ever use those shells. Could well be that the "editor"
metaphor is more common for shells than I thought. It's also
quite possible that people get used to it; but I think the
learning curve is quite a bit steeper.
>> Frankly, I don't think that "Editor window" is a good metaphor for the
>> *Python Shell*. The main purpose is to execute commands issued by the
>> user - something usually accomplished with a _shell_, not an editor
>
>maybe you should look outside the box?
I've tried to explain why the "Shell" metaphor seems superior to the "Editor"
metaphor. Maybe I've forgot some important aspect in favor of the "Editor"
metaphor - could you be more specific? Or do you mean that I should look for
different metaphors altogether?
Have fun!
Albert
From Albert.Brandl@edvg.co.at Tue Mar 7 12:56:00 2000
From: Albert.Brandl@edvg.co.at (Albert Brandl)
Date: Tue, 7 Mar 2000 13:56:00 +0100
Subject: [Idle-dev] IDLE interpreter window
Message-ID:
>In Albert's defense, I've often wished that a click in the PyShell
>window would move the cursor to the command line, and also that typing
>would automatically go into the command line.
>
>Albert is probably an example of a typical newbie who's seen xterms
>and DOS windows only, both of which have this interface (Emacs is
>definitely not for newbies :-).
I definitely don't agree with that "newbie" part. But otherwise I've got
to thank you for sharing your experience (which is surprisingly close
to mine)!
>[...] I've often confused myself by editing a previously
>executed command in place rather than copying it to the command line
>or using the history commands.
Me too. The problem is that the semantics of the window is very different
from anything I've used before for developing Python programs (not
_completely_ true: WinPython uses the same kind of Shell). And I'm quite
sure that people new to IDLE will encounter similar problems.
>Maybe a fully editable PyShell window should be an option for advanced
>users.
Since it is already implemented and is "widely accepted <0.5 wink>":
definitely!
Would it be much work to change the metaphor from "Editor" to "Shell"?
I'd like to contribute, if possible.
Yours,
Albert
From Fredrik Lundh"
Message-ID: <002f01bf8838$5b210520$34aab5d4@hagrid>
Albert Brandl wrote:
> >> Frankly, I don't think that "Editor window" is a good metaphor for =
the
> >> *Python Shell*. The main purpose is to execute commands issued by =
the
> >> user - something usually accomplished with a _shell_, not an editor
> >
> >maybe you should look outside the box?
>=20
> I've tried to explain why the "Shell" metaphor seems superior to the =
"Editor"
> metaphor. Maybe I've forgot some important aspect in favor of the =
"Editor"
> metaphor - could you be more specific? Or do you mean that I should =
look for
> different metaphors altogether?
why not?
start by considering *why* you think that
the editor version is harder to use.
maybe there's some other design that makes
even more sense, especially to people who've
never seen a "shell" or an "editor" before.
(fwiw, I'm think there is. but that's me ;-)
From faassen@vet.uu.nl Tue Mar 7 13:58:02 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Tue, 7 Mar 2000 14:58:02 +0100
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To: <000001bf85aa$fd6432c0$b02d153f@tim>
References: <000001bf85aa$fd6432c0$b02d153f@tim>
Message-ID: <20000307145802.A14364@vet.uu.nl>
Tim Peters wrote:
> [Albert Brandl, misses shell history features in IDLE, likes them in
> PythonWin]
>
> [it's pointed out that IDLE has them too]
>
> [Mark Hammond, PythonWin's dad]
> > hehe - Id love to take the credit, but I stole them from IDLE - isnt it
> > Alt-N and Alt-P or something?
>
> [Albert Brandl
> > Thanks for the advice. But the presence of a work-around for accessing
> > the history does not hide the fact that the *Python Shell* looks like
> > a shell but does not behave like one. IMHO it should try to resemble
> > the usual shell behaviour as closely as possible
>
> What is "usual shell behaviour"? There are dozens of shells out there.
> You're putting way too much weight on the word "shell", methinks: the
> Python Shell is really an editor window, that happens to have the added
> feature of being able to execute Python in interactive mode. Do Help->Help
> to read about the features "the shell" window has that IDLE's other editing
> Windows don't have; it also has all the features of an IDLE editing window.
Yes, but I observed the same problems as Albert did when demo-ing Python
in the IDLE shell yesterday. It's more easy to make mistakes than in the
regular (readline based) Python shells such the ones you find on Unix
and DOS. It's too easy to do something wrong and suddenly you get a
syntax error while everything 'looks' okay. It's just simply not any
use for the cursur to move around to different lines in the IDLE shell
window, the only thing you can do with that is cause problems.
> > (Gerrit's idea of introducing "modes" points to this direction). I think
> > that everyone who uses shells expects a certain behaviour when using
> > the *Python Shell*. And I _don't_ think many people expect the cursor
> > to go up one line when pressing the Up-Arrow ;-)
>
> If they think of it as an editor window instead (which it is, by design and
> by implementation), that behavior for Up-Arrow is certainly expected.
Yes, but completely useless, and it can give you buggy behavior if you ever
press it.
> > Another example: It's possible to remove the ">>>" by using the backspace
> > key. Ever done that at a bash / csh / tcsh prompt? ;-)
>
> No, and that's one reason the IDLE "shell" is much better. Not kidding! I
> use it heavily, and the ability to edit the shell window in arbitrary ways
> is *great* for saving the important parts of an interactive session.
[experiments some more with the window]
It's interesting that you can go up to an earlier >>> and press return and
get the same line copied onto the active prompt at the bottom. Less useful
is that when you edit it, then press return, only the non-edited part
shows up.
Evil is that when you press backspace at a new prompt, then type a space
again, then type an expression, Python gives you a SyntaxError. Weird that
if you *don't* type the space again, it works fine.
I don't think it's great when you can edit interactive sessions like that;
I expect a shell window to have a history (on the screen) that's immutable.
Wouldn't it be easier if there was some way to select an area in a window,
press some key combo, and a new window pops up with that code in there? You
can edit it all alike, there.
Anyway, the Python shell is in my opinion something different than a
Python module file. While you'd like some things like syntax highlighting
in either, I don't think it's a good idea to share a lot of the other
behavior between the two.
> > ...
> > I think the semantics of the arrow keys and backspace are essential if
> > the *Python Shell* window is to be widely accepted.
>
> Too late: it's already widely accepted <0.5 wink>.
some-things-widely-accepted-are-not-very-good-ideas-ly yours,
Martijn
From faassen@vet.uu.nl Tue Mar 7 14:49:16 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Tue, 7 Mar 2000 15:49:16 +0100
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To: <002f01bf8838$5b210520$34aab5d4@hagrid>
References: <002f01bf8838$5b210520$34aab5d4@hagrid>
Message-ID: <20000307154916.B14364@vet.uu.nl>
Fredrik Lundh wrote:
[snip]
> start by considering *why* you think that
> the editor version is harder to use.
This may be an implementation problem, but:
c is the cursor location
>>> c
press backspace
>>>c
press space
>>> c
type expression:
>>> 1 + 1
SyntaxError: invalid syntax
Nasty problem.
> maybe there's some other design that makes
> even more sense, especially to people who've
> never seen a "shell" or an "editor" before.
A shell is a place where you give commands one by one, which are
executed one by one.
An editor is a place where you prepare a list of commands, which then
later can be run all at once.
A hybrid could be a seperate area where you can enter a list of commands,
which then with a simple command can be run at the same time. i.e:
--------------------
output/input history
--
input area
--------------------
What is confusing currently about Idle is that when you execute a program,
the shell window is used for output. But you don't see any 'history' then,
you just seem output appear out of the blue:
>>> 1 + 1
2
>>>
Hello world
Nicer would be something like:
>>> 1 + 1
2
>>> [run hello.py]
Hello world
Though I myself still have some questions with doing this at all; I'd like
to see my program output appear in some fresh window, and cleared each time
I execute the program.
Also a paned view would be nice here -- I want the output window to be
always there, in the location I want to. I don't want a new output window
to appear each time I run something. Emacs Python-mode is nice this way.
A seperate issue is that Idle seems to remember old module states when I
run the same script again, with some code changed. Perhaps this is good if
you want to interact with your modules from the shell, but for me it got very
confusing. Idle kept giving traceback containing errors which I already
had corrected in the sources! I ended up giving up and ran my program from
the command line instead.
Regards,
Martijn
From dscherer@evergames.kssacct.com Tue Mar 7 15:12:16 2000
From: dscherer@evergames.kssacct.com (David Scherer)
Date: Tue, 07 Mar 2000 10:12:16 -0500
Subject: [Idle-dev] IDLE interpreter window
Message-ID: <3236164384.952423936@ZAPHOD>
> Though I myself still have some questions with doing this at all; I'd like
> to see my program output appear in some fresh window,
The output from "run script" should definitely go to a separate window from
the shell. In particular, we would like to disable the shell by default,
but we still need to see standard output! There are also different design
goals for a pure output window and a shell window.
> and cleared each time I execute the program.
I think the output window *should* remember the results of successive runs,
but they should be clearly delimited. A good compromise would be to scroll
the output window at the beginning of each run so that the first output line
of that run is at the top:
Output of run n-2
Output of run n-1
------------------- top of window
Output of run n
That way you can scroll back to see previous results, but you won't be
confused by them.
> Also a paned view would be nice here -- I want the output window to be
> always there, in the location I want to. I don't want a new output window
> to appear each time I run something.
Agreed. Creating a new window for each run requires the user to play a
frustrating game of "whack-a-mole" with the output windows. We are fighting
this problem with our graphics library (which must pop up one or more
*extra* windows under the program's control).
> A seperate issue is that Idle seems to remember old module states when I
> run the same script again, with some code changed. Perhaps this is good if
> you want to interact with your modules from the shell, but for me it got
very
> confusing. Idle kept giving traceback containing errors which I already
> had corrected in the sources! I ended up giving up and ran my program from
> the command line instead.
This is an artefact of the way Idle runs programs in its own interpreter.
Once a module is imported, it stays imported until you explicitly reload it,
even across multiple runs.
Moving to a model where the user program executes in a separate process
addresses this and many other problems.
Dave
From hei@adtranzsig.de Tue Mar 7 15:27:22 2000
From: hei@adtranzsig.de (Dirk-Ulrich Heise)
Date: Tue, 7 Mar 2000 16:27:22 +0100
Subject: [Idle-dev] IDLE interpreter window
Message-ID: <01bf8849$a24f2830$13ec1fc2@pc696.adtranzsig.de>
David Scherer:
>This is an artefact of the way Idle runs programs in its own interpreter.
>Once a module is imported, it stays imported until you explicitly reload
it,
>even across multiple runs.
>
>Moving to a model where the user program executes in a separate process
>addresses this and many other problems.
Do you mean that every time the user fixes an error in one of the modules,
he would have to reload the whole project? This would increase
the turn around time. IMHO, one should find a way to exploit the dynamism
of Python by just reloading the changed functions into the right namespaces.
(Maybe this could be an option for advanced users, but it can save a lot
of time in larger projects. It's possible via setattr.)
Would this be possible with a separate process for the user program?
Admittedly, sometimes you lose control, so an explicit reset (forcing a
full reload) would be a needed function.
Dirk
From guido@python.org Tue Mar 7 15:35:17 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 10:35:17 -0500
Subject: [Idle-dev] IDLE interpreter window
In-Reply-To: Your message of "Tue, 07 Mar 2000 16:27:22 +0100."
<01bf8849$a24f2830$13ec1fc2@pc696.adtranzsig.de>
References: <01bf8849$a24f2830$13ec1fc2@pc696.adtranzsig.de>
Message-ID: <200003071535.KAA13955@eric.cnri.reston.va.us>
> David Scherer:
> >This is an artefact of the way Idle runs programs in its own interpreter.
> >Once a module is imported, it stays imported until you explicitly reload
> it, even across multiple runs.
> >
> >Moving to a model where the user program executes in a separate process
> >addresses this and many other problems.
Dirk Heise:
> Do you mean that every time the user fixes an error in one of the modules,
> he would have to reload the whole project? This would increase
> the turn around time.
Yes, but the required analysis to avoid this is quite tricky. The
plans to run everything in a separate process will require a full
reload anyway.
> IMHO, one should find a way to exploit the dynamism
> of Python by just reloading the changed functions into the right namespaces.
> (Maybe this could be an option for advanced users, but it can save a lot
> of time in larger projects. It's possible via setattr.)
*Really* advanced users can already do this, using reload(). I think
it shouldn't be too hard to have a command "reload this class" or
"recompile this function". In Python 1.6, I want to make the
func_code attribute of function objects writable.
> Would this be possible with a separate process for the user program?
Shouldn't make much of a difference, assuming we have a remote proces
control interface (which we need anyway for the remote debugger).
> Admittedly, sometimes you lose control, so an explicit reset (forcing a
> full reload) would be a needed function.
Yes, this is much safer in the light of typical unpredictable newbie
behavior.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From tony@lsl.co.uk Tue Mar 7 15:56:11 2000
From: tony@lsl.co.uk (Tony J Ibbs (Tibs))
Date: Tue, 7 Mar 2000 15:56:11 -0000
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <200003071535.KAA13955@eric.cnri.reston.va.us>
Message-ID: <001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk>
Various people have been commenting on whether the IDLE shell is a "natural"
interface or not, and comparing it with other similar beasts (notably the
shell interface in [X]Emacs).
I must admit that, although I've been using [X]Emacs for some while now
(um - since Emacs on VMS in the early 1980s), I've never gotten sufficiently
comfortable with the way that it handles its shell window to actually *use*
the thing. I find the IDLE/PythonWin/[X]Emacs shell window paradigms
confusing - they don't seem to me to be one thing or t'other.
What do I expect? Perhaps something closer to the model found on the old
Apollo "not-quite-Unix" boxes. The console/shell/call-it-what-you-will
window had a line at the bottom which was where you were typing. This was
separated by a thin line from the rest of the window above it, which was the
"history" - everything that was readonly, so stuff you had typed and system
responses to it (obviously, a prompt had to be dealt with differently, and I
assume it would have gone into the "typing" line - this *is* a good while
ago). Typeahead worked, but I can't remember if you saw it (which would have
meant potentially increasing the number of lines shown in the typing area).
If you wanted an old line, you copied it with the normal editing mechanisms
for copying (there was a built in editor, and the "history" area was akin to
a text file - in fact, since the system actually kept a log of your session
for you, it probably *was* just a text file! presumably in readonly mode)
down into the "typing" line.
So, in brief, one area for input and the rest for "stuff I've done/stuff
that has happened".
I find the IDLE/etc. model confusing because it intertwingles these two
ideas. I can never remember quite what is going to happen if I move the
cursor up (hmm - no, it doesn't scroll stuff in my bottom line - oh dear, so
it's not like my "normal" shell - but it is *labelled* as a shell), whether
it matters if I'm at the end of a line when I hit "return", what happens if
I try to edit a line in my past history (!!! what a concept !!!) and then
hit return, and so on. I can't remember if you can do that last in IDLE, but
it can be a major confusion in [X]Emacs - the past is no longer what it was!
Sorry for the long post - does that make any sense?
(BTW: regardless, IDLE and PythonWin are seriously neat, and I *especially*
love having my interactive session stuff colourised)
Tibs
--
Tony J Ibbs (Tibs) http://www.tibsnjoan.demon.co.uk/
Well we're safe now....thank God we're in a bowling alley.
- Big Bob (J.T. Walsh) in "Pleasantville"
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)
From jeremy@cnri.reston.va.us Tue Mar 7 16:02:34 2000
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Tue, 7 Mar 2000 11:02:34 -0500 (EST)
Subject: [Idle-dev] What we need, and how we can help
In-Reply-To:
References:
Message-ID: <14533.10266.894374.813812@goon.cnri.reston.va.us>
>>>>> "DS" == David Scherer writes:
DS> We plan to put a significant amount of effort into bringing a
DS> development environment to that level. If the evolution of IDLE
DS> can dovetail with our needs, as we believe it can, then we will
DS> be happy to contribute to IDLE. If not, we would still like to
DS> share as much concept and code as possible.
It certainly sounds like there is an opportunity to share concepts and
code here. Many of the requirements you have for a development
environment are ones we want to see in IDLE anyway.
DS> Here's what we think we need. Some of this fits in with what
DS> Guido has already said about the future of IDLE, and some of it
DS> reflects a difference in focus. We are, of course, content to
DS> have features in our environment that are unimportant to us, so
DS> long as they can be configured to be unobtrusive.
DS> 1. The IDE *must* be stable in the face of any correct or
DS> incorrect user program (e.g. infinite loops, access to Tcl/Tk
DS> and the window system, etc.). The user program also needs to
DS> start in a fresh interpreter so that its behavior cannot be
DS> affected by previous runs. Given the complexities of shared
DS> access to libraries, this almost certainly means a separate OS
DS> process for the user program. We have prototyped a simple IDLE
DS> extension that runs programs this way, but it does not yet
DS> permit adequate error reporting or debugging.
This is an essential feature for program development, too! There are
far too many opportunities to corrupt the program being developed or
IDLE itself when the user program runs in the IDLE process. It's
useful to be able to open up a shell and run several programs in it or
to open up a shell that is in the IDLE process, but both of these are
expert features.
DS> 2. Interactive mode is not very important to us, at least for
DS> now.
DS> - It is impossible to reverse changes. When a student makes a
DS> mistake in an editor environment, pressing "undo" a few times
DS> and re-running the program suffices to correct it. In
DS> interactive mode there is no obvious way to reverse actions
DS> which had side effects on the environment. At present there
DS> isn't even an easy way to start over.
We've actually thought some about implementing a reversible debugger
that would let you step forwards or backwards. It's not a high
priority item for us, because it will be a lot of work to implement.
The basic approach people have taken to reverse debugging is to back
up by re-running the program but not as far. To make this efficient,
you need to be able to checkpoint the process periodically.
Checkpointing seems to be the chief stumbling block; there is no
simple, portable approach that I'm aware of. Of course, reverse
execution is also complicated in the face of I/O and other externally
visible side-effects.
DS> 3. Given that students will be writing all of their code in the
DS> editor rather than the interactive window, and that we wish to
DS> encourage a highly iterative development process, it is
DS> important that the process of running programs from the editor
DS> be as streamlined as possible. Ideally, editing a program
DS> should be as subjectively responsive as interactive mode. One
DS> keystroke to execute a program is better than two or three.
Absolutely. The current interface for running programs is clumsy and
confusing. There are too many keystrokes, and there is no clear
feedback that the program has been run.
DS> Program output needs to be organized on the screen so that
DS> students don't need to change focus or play whack-a-mole with
DS> output windows. It needs to be easy to terminate a program.
Can you say a little more about what you are interested in? I imagine
you want multiple "buffers" to be displayed in a single window. IDLE
doesn't support that yet, but I think it needs to. (I was using IDLE
for some programming over the weekend and quickly ended up with a
dozen editor windows plus shells, grep output, etc. "whack-a-mole" is
an excellent description.)
DS> 5. Error reporting is *very* important.
DS> - Syntax errors and exceptions should be presented in the same
DS> way even though they are reported through different mechanisms.
What is the difference you are referring to? If I get a SyntaxError,
the shell window shows the following output:
>>>
File "/tmp/fact.py", line 2
if (= n 0):
^
SyntaxError: invalid syntax
I can right-click on the 'File ...' line and it will jump to that
location in the editor window.
Other exceptions produce much the same output.
DS> - Highlighting the offending source code is a must. The right
DS> code, or a superset, always needs to be highlighted. Something
DS> as simple as the following can really confuse a novice:
line((1,2),(3,4) # error is here
line((1,2),(3,4)) # but is reported on this line
Not sure what this example is supposed to show. What is the error?
Why are the two lines identical?
It's clear that the showing the code that caused the exception is
a requirement. I'm just not sure how it fails to do that currently.
I'm not saying that it never fails; I'm just not sure how.
DS> - Tracebacks should not by default extend into "system"
DS> modules, even if those modules are implemented in Python.
DS> Exactly how the IDE decides what is a system module depends on
DS> whether and how it supports projects. Anything that is open in
DS> an editor window or part of the current project is not a system
DS> module.
Yes.
DS> - Error messages need to be as specific and clear as possible.
DS> Lots of the messages currently returned by Python and its
DS> libraries could stand to be rewritten with the novice programmer
DS> in mind.
Yes.
DS> More precise identification of syntactical errors
DS> would also be very helpful - "Missing )" is much better than
DS> just "Syntax error".
It's not trivial to determine what the cause of the syntax error was.
It would be a nice feature, but the approach seems involved and mostly
ad hoc.
DS> 6. Cross-platform support is important. Windows, Unix, and
DS> Macintosh all need to be supported. The latter is obviously
DS> most difficult. IDLE can easily be made to start on the Mac,
DS> but there are serious stability problems with Tkinter. We are
DS> investigating those, but any advice would be appreciated.
Cross-platform support is important for IDLE, too. One of its target
audiences is educators and students, where the Mac is still a common
platform. I don't do an Macintosh development, though; perhaps Guido
can say more about what the Tk/Tkinter issues are.
DS> 7. We plan to distribute a single installer to students in the
DS> course (and to anyone else who is interested), which will
DS> include Python, our visualization library, an IDE that suits our
DS> needs, and all the libraries such as Numeric and Tcl/Tk which
DS> the first three components require.
Sure.
DS> - We have developed a prototype Windows installer which
DS> differs from the standard Python installer in several important
DS> ways, including integrating an *unshared* copy of Tcl/Tk. We
DS> believe it will reduce the number of installation problems
DS> significantly.
I believe Guido intends to use an unshared copy of Tcl/Tk for future
Python releases as well.
DS> - If Python and IDLE are adopted in education on any scale,
DS> many other people will want to roll their own distributions for
DS> similar reasons. The process could be streamlined considerably
DS> - for example, by making the source for existing installers
DS> available. Another issue which bears consideration is how
DS> multiple distributions should coexist on the same machine.
The current Python install script is a Wise installer. Again, I don't
know much about how this works. Hopefully, Guido will chime in here,
too.
Jeremy
From KRodgers@ryanaero.com Tue Mar 7 16:04:19 2000
From: KRodgers@ryanaero.com (Rodgers, Kevin)
Date: Tue, 7 Mar 2000 08:04:19 -0800
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
Message-ID: <0D8C1A50C283D311ABB800508B612E5354B3C3@ryanaero.com>
There is a commercial app I use everyday (Xmath from Integrated Systems, now
Wind River) that has the "paned" window with output on the top, command line
(actually, a multi-line command window) in the middle, and error message
window on the bottom. This sounds similar to what Tibs is describing here.
I am generally pleased with this arrangement; my only complaint is that on
Windows (not on Unix) the Xmath interface isn't focus-follows-mouse; i.e.,
you have to explicitly click on the command pane to direct keystrokes there
(the Unix version directs the focus to the command pane whenever the overall
window has the focus, regardless of whether the overall focus is
click-to-type or focus-follows-mouse). Something to think about!
--
Kevin Rodgers Northrop Grumman Ryan Aeronautical krodgers@ryanaero.com
> -----Original Message-----
> From: Tony J Ibbs (Tibs) [SMTP:tony@lsl.co.uk]
> Sent: Tuesday, March 07, 2000 7:56 AM
> To: Idle-dev@python.org
> Subject: RE: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
>
[deleted]
> What do I expect? Perhaps something closer to the model found on the old
> Apollo "not-quite-Unix" boxes. The console/shell/call-it-what-you-will
> window had a line at the bottom which was where you were typing. This was
> separated by a thin line from the rest of the window above it, which was
> the
> "history" - everything that was readonly, so stuff you had typed and
> system
> responses to it (obviously, a prompt had to be dealt with differently, and
> I
> assume it would have gone into the "typing" line - this *is* a good while
> ago). Typeahead worked, but I can't remember if you saw it (which would
> have
> meant potentially increasing the number of lines shown in the typing
> area).
>
> If you wanted an old line, you copied it with the normal editing
> mechanisms
> for copying (there was a built in editor, and the "history" area was akin
> to
> a text file - in fact, since the system actually kept a log of your
> session
> for you, it probably *was* just a text file! presumably in readonly mode)
> down into the "typing" line.
>
> So, in brief, one area for input and the rest for "stuff I've done/stuff
> that has happened".
>
From guido@python.org Tue Mar 7 16:06:24 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 11:06:24 -0500
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: Your message of "Tue, 07 Mar 2000 15:56:11 GMT."
<001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk>
References: <001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk>
Message-ID: <200003071606.LAA14525@eric.cnri.reston.va.us>
> So, in brief, one area for input and the rest for "stuff I've done/stuff
> that has happened".
I've worked with systems where the input and output area were
phyisically separate, and they confused me.
But I do like the bash-in-an-xterm model (For Windows 9x users,
DOSKEY; for NT users, a DOS box): it looks like a single text area,
and you can select text anywhere with the mouse for copying, but you
can only ever edit the current command line.
> I find the IDLE/etc. model confusing because it intertwingles these two
> ideas. I can never remember quite what is going to happen if I move the
> cursor up (hmm - no, it doesn't scroll stuff in my bottom line - oh dear, so
> it's not like my "normal" shell - but it is *labelled* as a shell), whether
> it matters if I'm at the end of a line when I hit "return", what happens if
> I try to edit a line in my past history (!!! what a concept !!!) and then
> hit return, and so on. I can't remember if you can do that last in IDLE, but
> it can be a major confusion in [X]Emacs - the past is no longer what it was!
>
> Sorry for the long post - does that make any sense?
>
> (BTW: regardless, IDLE and PythonWin are seriously neat, and I *especially*
> love having my interactive session stuff colourised)
My plan is for the next version of IDLE to *look* exactly the way it
currently looks, but to completely disallow you from editing the text
before the beginning of the current command. This shouldn't be too
hard (the undo framework already intercepts all changes, all I have to
do is add a hook that rejects certain changes).
This is, by the way, how DrScheme's interactive buffer works. I
played with it a bit and I like it. If only Matthias wasn't such a
curmudgeon. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
From tony@lsl.co.uk Tue Mar 7 16:15:48 2000
From: tony@lsl.co.uk (Tony J Ibbs (Tibs))
Date: Tue, 7 Mar 2000 16:15:48 -0000
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <200003071606.LAA14525@eric.cnri.reston.va.us>
Message-ID: <001e01bf8850$669cda60$f0c809c0@lslp7o.lsl.co.uk>
Guido van Rossum wrote:
> I've worked with systems where the input and output area were
> phyisically separate, and they confused me.
Ah...
> But I do like the bash-in-an-xterm model (For Windows 9x users,
> DOSKEY; for NT users, a DOS box): it looks like a single text area,
> and you can select text anywhere with the mouse for copying, but you
> can only ever edit the current command line.
Aha...
I don't particularly care whether there is a "physical" separator visible,
since as far as I can see that's the only difference between the two
approaches!
> My plan is for the next version of IDLE to *look* exactly the way it
> currently looks, but to completely disallow you from editing the text
> before the beginning of the current command. This shouldn't be too
> hard (the undo framework already intercepts all changes, all I have to
> do is add a hook that rejects certain changes).
Well, it's not *quite* the time machine in action, but it certainly sounds
like it will make me happy (in the future) anyway...
Thanks in advance, Tibs
--
BikeCode0.2 http://www.tibsnjoan.demon.co.uk/bikecode.html
P: [Tibs] Tc B10 K:++ i29:30" h1.65m n1960 H+:~ v~ A+ M+ Rg-
B: [AnthroTech] 3tRu U1c w37" Wr19:406 Mfr SAf bDh[Sachs]:C
G3x7 8s Lrr1B Cb[Michael] VjsX col[MidnightBlue]
T: [BurleyD'Lite] 2c2[Thomas] f++ VsX
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)
From faassen@vet.uu.nl Tue Mar 7 16:44:48 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Tue, 7 Mar 2000 17:44:48 +0100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <200003071606.LAA14525@eric.cnri.reston.va.us>
References: <001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk> <200003071606.LAA14525@eric.cnri.reston.va.us>
Message-ID: <20000307174448.A14587@vet.uu.nl>
Guido van Rossum wrote:
> > So, in brief, one area for input and the rest for "stuff I've done/stuff
> > that has happened".
>
> I've worked with systems where the input and output area were
> phyisically separate, and they confused me.
Yes, it would probably get clunky. An advantage of a seperate input area
would be that you could for instance enter an entire class definition
(including newlines between or in methods) at once, something the
current shell doesn't allow. Disadvantage of that is that you need somekind
of special button or key combo to 'enter' the code, instead of the
enter key. This will likely get terribly clunky.
I myself do feel the same confusion if I use certain mud clients that
seperate input from output. 'tinyfugue' (a command line mud client) allows
both options; you can set an option to have a special input area or you
can just use the bottom line.
> But I do like the bash-in-an-xterm model (For Windows 9x users,
> DOSKEY; for NT users, a DOS box): it looks like a single text area,
> and you can select text anywhere with the mouse for copying, but you
> can only ever edit the current command line.
Yes, that's the tinytugue model (with 'visual off') too. I'd be comfortable
with that myself.
[snip]
> My plan is for the next version of IDLE to *look* exactly the way it
> currently looks, but to completely disallow you from editing the text
> before the beginning of the current command. This shouldn't be too
> hard (the undo framework already intercepts all changes, all I have to
> do is add a hook that rejects certain changes).
Sounds good to me. What about bash/readline style history behavior? i.e.
press the 'up' key and you go through your history?
Emulating 'bash' style behavior would also fix the backspace trouble I
described earlier; in a bash shell you can't backspace through its
prompt. :)
Regards,
Martijn
From tony@lsl.co.uk Tue Mar 7 17:02:17 2000
From: tony@lsl.co.uk (Tony J Ibbs (Tibs))
Date: Tue, 7 Mar 2000 17:02:17 -0000
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <20000307174448.A14587@vet.uu.nl>
Message-ID: <002a01bf8856$e48b6990$f0c809c0@lslp7o.lsl.co.uk>
Martijn Faassen wrote:
> Guido van Rossum wrote:
> > So, in brief, one area for input and the rest for "stuff I've
> > done/stuff that has happened".
> >
> > I've worked with systems where the input and output area were
> > phyisically separate, and they confused me.
>
> Yes, it would probably get clunky. An advantage of a seperate input area
> would be that you could for instance enter an entire class definition
> (including newlines between or in methods) at once, something the
> current shell doesn't allow. Disadvantage of that is that you
> need somekind of special button or key combo to 'enter' the code,
> instead of the enter key. This will likely get terribly clunky.
OK - I see now that my original description has led to confusion. The
"separate input area" *was* just the current line that was being typed (and
*possibly* the current lines that had been typed and not yet acted on, if
typeahead worked in the obvious manner). The character to 'enter' the code
was the enter key. Which is why, in reply to Guido, I was happy with his
future plans - as far as I can see the only difference between what he is
proposing and (more or less) what I was describing is the presence or
absence of a horizontal line between the current command line and the
"history". And I don't care if that's there or not...
Tibs
--
Tony J Ibbs (Tibs) http://www.tibsnjoan.demon.co.uk/
Feet first with 5 wheels...
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)
From guido@python.org Tue Mar 7 17:04:42 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 12:04:42 -0500
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: Your message of "Tue, 07 Mar 2000 17:44:48 +0100."
<20000307174448.A14587@vet.uu.nl>
References: <001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk> <200003071606.LAA14525@eric.cnri.reston.va.us>
<20000307174448.A14587@vet.uu.nl>
Message-ID: <200003071704.MAA14786@eric.cnri.reston.va.us>
> Yes, it would probably get clunky. An advantage of a seperate input area
> would be that you could for instance enter an entire class definition
> (including newlines between or in methods) at once, something the
> current shell doesn't allow.
Hm, interesting. It *almost* lets you do that. You can actually
paste in an entire class, but you can't enter one by typing: you'd
have to put comment signs on the blank lines.
> Disadvantage of that is that you need somekind
> of special button or key combo to 'enter' the code, instead of the
> enter key. This will likely get terribly clunky.
And this is exactly why I like the shell mode so much: the return
usually does what you want.
> I myself do feel the same confusion if I use certain mud clients that
> seperate input from output. 'tinyfugue' (a command line mud client) allows
> both options; you can set an option to have a special input area or you
> can just use the bottom line.
I've never used muds, but I've seen a few of the interfaces and they
look tedious to use. Like chats, really (also never used, but seen).
> > But I do like the bash-in-an-xterm model (For Windows 9x users,
> > DOSKEY; for NT users, a DOS box): it looks like a single text area,
> > and you can select text anywhere with the mouse for copying, but you
> > can only ever edit the current command line.
>
> Yes, that's the tinytugue model (with 'visual off') too. I'd be comfortable
> with that myself.
Am I really supposed to know what tinytugue is? Don't tell me unless
it's relevant to this discussion. :-)
> Sounds good to me. What about bash/readline style history behavior? i.e.
> press the 'up' key and you go through your history?
That would come naturally.
> Emulating 'bash' style behavior would also fix the backspace trouble I
> described earlier; in a bash shell you can't backspace through its
> prompt. :)
I don't care about emulating bash exactly, but I plan to make
everything in the buffer up to and including the prompt read-only, so
this would have the same effect.
Those shell folks knew what they were doing!
(Note that bash didn't invent any of this; ksh was way earlier, and
maybe tcsh is even older. It's just that bash is the form that people
are most familiar with.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
From faassen@vet.uu.nl Tue Mar 7 17:15:54 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Tue, 7 Mar 2000 18:15:54 +0100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <002a01bf8856$e48b6990$f0c809c0@lslp7o.lsl.co.uk>
References: <20000307174448.A14587@vet.uu.nl> <002a01bf8856$e48b6990$f0c809c0@lslp7o.lsl.co.uk>
Message-ID: <20000307181554.A14654@vet.uu.nl>
Tony J Ibbs (Tibs) wrote:
> OK - I see now that my original description has led to confusion. The
> "separate input area" *was* just the current line that was being typed (and
> *possibly* the current lines that had been typed and not yet acted on, if
> typeahead worked in the obvious manner). The character to 'enter' the code
> was the enter key.
I'm not sure if your original description led to confusion, I was just
speculating vaguely myself about such a setup, but concluded that such
a setup of my own speculation would be clunky. :)
> Which is why, in reply to Guido, I was happy with his
> future plans - as far as I can see the only difference between what he is
> proposing and (more or less) what I was describing is the presence or
> absence of a horizontal line between the current command line and the
> "history". And I don't care if that's there or not...
Well, if the line is there you may be dealing with two widgets and into the
resulting focusing problems, if the line is absent you're dealing with the
same widget. But ignoring technical details, yeah, the presence of the
seperator seems to be the only difference.
Personally, I'd rather not have the seperator there, as I've noticed that
in situations with seperator it confuses me. My mind seems to expect that
when I type a line of input, that line should scroll up (or the input prompt
scrolls down, depending if one is at the bottom of the window yet or not),
becoming part of the 'history'. With a visual seperator there my mind doesn't
see that anymore, confusing me. The input may become seperated from where
it appears (I type something in the input area, and what I type appears
at the top of the screen..weird).
Regards,
Martijn
From guido@python.org Tue Mar 7 17:19:40 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 12:19:40 -0500
Subject: [Idle-dev] What we need, and how we can help
In-Reply-To: Your message of "Tue, 07 Mar 2000 11:02:34 EST."
<14533.10266.894374.813812@goon.cnri.reston.va.us>
References:
<14533.10266.894374.813812@goon.cnri.reston.va.us>
Message-ID: <200003071719.MAA14887@eric.cnri.reston.va.us>
Jeremy wrote:
> line((1,2),(3,4) # error is here
> line((1,2),(3,4)) # but is reported on this line
>
> Not sure what this example is supposed to show. What is the error?
> Why are the two lines identical?
The lines aren't identical -- the first one is missing a close paren.
The fact that you missed this shows how important it is to have a
better diagnostic for this!
E.g. showing where the first open paren is that is missing a close
paren...
This so common, it's almost worth special-casing by hook or by crook!
> I believe Guido intends to use an unshared copy of Tcl/Tk for future
> Python releases as well.
Yes.
> The current Python install script is a Wise installer. Again, I don't
> know much about how this works. Hopefully, Guido will chime in here,
> too.
We use an old version of the WISE installer that can be used for free
by anyone who wants to create an installer for free Python software
(the friendly WISE people have told Mark Hammond this). I don't put
it on the web to avoid misuse -- I'll mail it to you if you ask. The
WISE installer script I use to create the installation is available as
part of the source distribution (or via CVS): PCbuild/python15.wse.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From jeremy@cnri.reston.va.us Tue Mar 7 18:17:17 2000
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Tue, 7 Mar 2000 13:17:17 -0500 (EST)
Subject: [Idle-dev] What we need, and how we can help
In-Reply-To: <200003071719.MAA14887@eric.cnri.reston.va.us>
References:
<14533.10266.894374.813812@goon.cnri.reston.va.us>
<200003071719.MAA14887@eric.cnri.reston.va.us>
Message-ID: <14533.18349.836542.92291@goon.cnri.reston.va.us>
>>>>> "GvR" == Guido van Rossum writes:
GvR> Jeremy wrote:
>> line((1,2),(3,4) # error is here
>> line((1,2),(3,4)) # but is reported on this line
>>
>> Not sure what this example is supposed to show. What is the
>> error? Why are the two lines identical?
GvR> The lines aren't identical -- the first one is missing a close
GvR> paren. The fact that you missed this shows how important it is
GvR> to have a better diagnostic for this!
Sigh. I guess that explains why I had to manually sync up the
comments to the same column after supercite reformatting.
Jeremy
From faassen@vet.uu.nl Tue Mar 7 17:21:58 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Tue, 7 Mar 2000 18:21:58 +0100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <200003071704.MAA14786@eric.cnri.reston.va.us>
References: <001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk> <200003071606.LAA14525@eric.cnri.reston.va.us> <20000307174448.A14587@vet.uu.nl> <200003071704.MAA14786@eric.cnri.reston.va.us>
Message-ID: <20000307182158.B14654@vet.uu.nl>
Guido van Rossum wrote:
> > I myself do feel the same confusion if I use certain mud clients that
> > seperate input from output. 'tinyfugue' (a command line mud client) allows
> > both options; you can set an option to have a special input area or you
> > can just use the bottom line.
>
> I've never used muds, but I've seen a few of the interfaces and they
> look tedious to use. Like chats, really (also never used, but seen).
Right -- but certain chat and mud clients work in the 'bash' mode, where
the input is near where the input appears, while in other clients
(the confusing ones) the input line is always at the bottom, even if
what you type appears at the top. That's what's confusing to me, I think.
In the mail I just sent to the list you can see me think through this.
[snip]
> > Yes, that's the tinytugue model (with 'visual off') too. I'd be comfortable
> > with that myself.
>
> Am I really supposed to know what tinytugue is? Don't tell me unless
> it's relevant to this discussion. :-)
I just mentioned it as a mud client and described its behavior, didn't I?
You must've missed that. Whoops, tinyfugue, I misspelled.
> > Sounds good to me. What about bash/readline style history behavior? i.e.
> > press the 'up' key and you go through your history?
>
> That would come naturally.
>
> > Emulating 'bash' style behavior would also fix the backspace trouble I
> > described earlier; in a bash shell you can't backspace through its
> > prompt. :)
>
> I don't care about emulating bash exactly, but I plan to make
> everything in the buffer up to and including the prompt read-only, so
> this would have the same effect.
>
> Those shell folks knew what they were doing!
Right, I didn't mean a complete bash emulation, just the main unix-shelly
features.
Regards,
Martijn
From pj@sam.engr.sgi.com Tue Mar 7 18:05:33 2000
From: pj@sam.engr.sgi.com (Paul Jackson)
Date: Tue, 7 Mar 2000 10:05:33 -0800 (PST)
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
References: <001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk>
<200003071606.LAA14525@eric.cnri.reston.va.us> <20000307174448.A14587@vet.uu.nl>
Message-ID: <200003071805.KAA02413@sam.engr.sgi.com>
|> bash didn't invent any of this; ksh was way earlier
Users of bash or the Public domain Korn shell (pdksh, or ksh
on Linux), might note that when recalling a multiline command
from the history, the shell scrunches the original multiline
form into an equivalent single line form. Annoying.
Thankfully, interactive Python (and Korn's original ksh on Bell
Labs Unix) got this right: preserving the multiline form when
recalling history.
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj
From guido@python.org Tue Mar 7 18:57:30 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 13:57:30 -0500
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: Your message of "Tue, 07 Mar 2000 18:21:58 +0100."
<20000307182158.B14654@vet.uu.nl>
References: <001d01bf884d$a8c58700$f0c809c0@lslp7o.lsl.co.uk> <200003071606.LAA14525@eric.cnri.reston.va.us> <20000307174448.A14587@vet.uu.nl> <200003071704.MAA14786@eric.cnri.reston.va.us>
<20000307182158.B14654@vet.uu.nl>
Message-ID: <200003071857.NAA15266@eric.cnri.reston.va.us>
OK, here's a patch. It was remarkably simple.
The following patch prevents all editing from having any effect before
the "I/O mark" -- an invisible marker in the text that delineates the
beginning of the command editing area, typically placed just after the
last prompt. You can still steer the cursor anywhere in the window
(unlike with a typical bash-in-an-xterm setup) but you can't type (or
delete or cut or paste) when you're not in the command area.
Please try this out, and let me know how it "feels"!
Note that there's still a way to confuse yourself: if you use undo
immediately after a fresh prompt, it will erase the prompt, and if you
hit undo repeatedly, it will erase more and more of the session -- but
not its effects on your workspace. I haven't decided yet if I want to
call that a feature.
Index: PyShell.py
===================================================================
RCS file: /projects/cvsroot/python/dist/src/Tools/idle/PyShell.py,v
retrieving revision 1.27
retrieving revision 1.28
diff -c -r1.27 -r1.28
*** PyShell.py 2000/03/07 17:55:32 1.27
--- PyShell.py 2000/03/07 18:51:49 1.28
***************
*** 15,20 ****
--- 15,21 ----
from EditorWindow import EditorWindow, fixwordbreaks
from FileList import FileList
from ColorDelegator import ColorDelegator
+ from UndoDelegator import UndoDelegator
from OutputWindow import OutputWindow
from IdleConf import idleconf
import idlever
***************
*** 127,132 ****
--- 128,155 ----
})
+ class ModifiedUndoDelegator(UndoDelegator):
+
+ # Forbid insert/delete before the I/O mark
+
+ def insert(self, index, chars, tags=None):
+ try:
+ if self.delegate.compare(index, "<", "iomark"):
+ self.delegate.bell()
+ return
+ except TclError:
+ pass
+ UndoDelegator.insert(self, index, chars, tags)
+
+ def delete(self, index1, index2=None):
+ try:
+ if self.delegate.compare(index1, "<", "iomark"):
+ self.delegate.bell()
+ return
+ except TclError:
+ pass
+ UndoDelegator.delete(self, index1, index2)
+
class ModifiedInterpreter(InteractiveInterpreter):
def __init__(self, tkconsole):
***************
*** 264,269 ****
--- 287,293 ----
# Override classes
ColorDelegator = ModifiedColorDelegator
+ UndoDelegator = ModifiedUndoDelegator
# Override menu bar specs
menu_specs = PyShellEditorWindow.menu_specs[:]
--Guido van Rossum (home page: http://www.python.org/~guido/)
From mhammond@skippinet.com.au Tue Mar 7 22:05:46 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Wed, 8 Mar 2000 09:05:46 +1100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <200003071704.MAA14786@eric.cnri.reston.va.us>
Message-ID:
> I don't care about emulating bash exactly, but I plan to make
> everything in the buffer up to and including the prompt read-only, so
> this would have the same effect.
I think it would be better to "do the right thing" when they type in the
existing buffer, rather than make it read-only. For example, I often delete
earlier text from these history windows.
Ive often thought that for Pythonwin, the preferred behaviour would be that
as soon as someone starts editing a previous command, the entire command is
copied to the end of the buffer, and edited in-place there - ie, simply
remove the requirement that "Enter" copies the block to the end - make it
_any_ editing character does this!
I also have a bit of a dilemma about what to do when someone presses enter
while editing a command, but they are not at the end of that command. Eg,
Im entering a 5 line function, and I scroll up to change line 2, then press
Enter.
> Those shell folks knew what they were doing!
I dunno - I think the editor window is far superior. I wonder what these
shells would look like had they been written when GUIs were ubiquitous? I
bet they would look different. This is not to suggest that what we have is
perfect, but IMO it is an improvement.
Anecdotally, Pythonwin is nearly 7 years old, and I have never one heard
that the interactive window should "look like a shell". I _have_ had a
handful of comments that it should be harder to edit a previous command.
Im thinking that styling could also be useful - eg, all previous text gets a
grey background, while the text you edit at the end of the buffer is white.
This could help reinforce the metaphor....
Mark.
From guido@python.org Tue Mar 7 22:35:38 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 17:35:38 -0500
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: Your message of "Wed, 08 Mar 2000 09:05:46 +1100."
References:
Message-ID: <200003072235.RAA19129@eric.cnri.reston.va.us>
> I think it would be better to "do the right thing" when they type in the
> existing buffer, rather than make it read-only. For example, I often delete
> earlier text from these history windows.
I do that too, because I can, but I don't think I'll miss it much.
You can always close PyShell and open a new one. (Maybe "reset"
should be a standard command.)
> Ive often thought that for Pythonwin, the preferred behaviour would be that
> as soon as someone starts editing a previous command, the entire command is
> copied to the end of the buffer, and edited in-place there - ie, simply
> remove the requirement that "Enter" copies the block to the end - make it
> _any_ editing character does this!
Not clear -- you could've accidentally moved the mouse away from the
command buffer; and what to do if something's already there? I've
been observing newbies lately, and some quite clumsy with the mouse,
often clicking where they shouldn't.
> I also have a bit of a dilemma about what to do when someone presses enter
> while editing a command, but they are not at the end of that command. Eg,
> Im entering a 5 line function, and I scroll up to change line 2, then press
> Enter.
In IDLE, it inserts a line at the insert point -- very handy if you
need to insert a line of code. If that wasn't what you expected, undo
and hit DOWN until you're at the end, then hit return. Newbies don't
mind this kind of stuff.
> > Those shell folks knew what they were doing!
>
> I dunno - I think the editor window is far superior. I wonder what these
> shells would look like had they been written when GUIs were ubiquitous? I
> bet they would look different. This is not to suggest that what we have is
> perfect, but IMO it is an improvement.
In the way that an Emacs shell buffer is an improvement over
bash-in-an-xterm.
> Anecdotally, Pythonwin is nearly 7 years old, and I have never one heard
> that the interactive window should "look like a shell". I _have_ had a
> handful of comments that it should be harder to edit a previous command.
And that's the same feedback we're now getting about IDLE -- the "look
like a shell" thing is a red herring -- what they really want is that
the editability reflects how much sense it makes to change text; you
shouldn't be able to edit output or past commands, since you can't
rewrite history.
> Im thinking that styling could also be useful - eg, all previous text gets a
> grey background, while the text you edit at the end of the buffer is white.
> This could help reinforce the metaphor....
Good idea. The foreground should continue to use syntax coloring and
the various color codings for stdout/stderr/IDLE diagnostics, of
course.
When should past output turn grey? When the new prompt appears? I
could experiment with that.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From dscherer@cmu.edu Tue Mar 7 22:53:13 2000
From: dscherer@cmu.edu (David Scherer)
Date: Tue, 7 Mar 2000 17:53:13 -0500
Subject: [Idle-dev] What we need, and how we can help
In-Reply-To: <14533.10266.894374.813812@goon.cnri.reston.va.us>
Message-ID:
> It certainly sounds like there is an opportunity to share concepts and
> code here. Many of the requirements you have for a development
> environment are ones we want to see in IDLE anyway.
Good!
> Of course, reverse
> execution is also complicated in the face of I/O and other externally
> visible side-effects.
A way to reverse all side-effects of an arbitrary program would be great.
If you get it working, I think it would be really useful for things other
than just Python programming (un-send e-mail, un-crash Windows... :)
Maybe Guido intends to release the source code for this time machine I keep
hearing about?
> DS> Program output needs to be organized on the screen so that
> DS> students don't need to change focus or play whack-a-mole with
> DS> output windows. It needs to be easy to terminate a program.
>
> Can you say a little more about what you are interested in? I imagine
> you want multiple "buffers" to be displayed in a single window. IDLE
> doesn't support that yet, but I think it needs to. (I was using IDLE
> for some programming over the weekend and quickly ended up with a
> dozen editor windows plus shells, grep output, etc. "whack-a-mole" is
> an excellent description.)
This is already being discussed in another thread. I don't have a complete
design to offer. I have suggested a scrolling output window which when the
program starts scrolls to hide the results of previous runs, e.g.:
| Hello, world!
|
| Hello, world!
| My program now prints two lines.
|
| -------------- Top of window (but you can scroll up past here)
| Hello, world!
| The following line is a quine:
| 'is not a quine' is not a quine
That alone might suffice to keep the window count reasonable in our
environment. We will be disabling the "Python Shell" window by default, and
most of our students will only be editing a single file containing their
program, which leaves just one editor window and one persistent output
window, plus any graphics windows the program creates.
> It's not trivial to determine what the cause of the syntax error was.
> It would be a nice feature, but the approach seems involved and mostly
> ad hoc.
I realize that it isn't easy. I don't know how feasable it is to get more
useful diagnostics out of the Python parser, but in the worst case we can at
least implement a few heuristics. We will attempt to collect some
unscientific data on the most commonly encountered errors, but unmatched
delimiters and missing ":"s seem very common.
> It's clear that the showing the code that caused the exception is
> a requirement. I'm just not sure how it fails to do that currently.
> I'm not saying that it never fails; I'm just not sure how.
I did a terrible job of explaining this, partly because I've been using
several different versions of IDLE, including some of my own hacks, and I
can't remember which ones do what anymore :) Let me just start over from a
slightly different perspective.
Tracebacks are useful to experienced programmers debugging complex
applications with deep call stacks. It is likely that one of the functions
along the call stack is responsible for causing an exception, but which one
might not be clear. Dumping the entire stack allows the programmer to
decide.
For a novice programmer writing a simple program calling complex libraries,
the traceback is not so useful:
|Traceback (innermost last):
| File "C:\python\Tools\idle_old\ScriptBinding.py",
|line 131, in run_module_event
| execfile(filename, mod.__dict__)
| File "C:\python\box.py", line 7, in ?
| print s.posiiton
| File "visual\prim.py", line 42, in __getattr__
|AttributeError: posiiton
Part of the problem here is something I mentioned before: the traceback
extends both "upwards" into IDLE's code and "downwards" into a library that
should be opaque to the programmer. Removing that part would yield just:
|Traceback (innermost last):
| File "C:\python\box.py", line 7, in ?
| print s.posiiton
|AttributeError: posiiton
Then you can right-click on the 2nd line and choose "Go to file/line" from a
context menu, at which point you see the code highlighted in your editor
window. Unfortunately, there is nothing to suggest to the user that they
can or should right-click on that particular line. This interface is also
unlike anything students are likely to have seen before, and it's
unnecessarily cumbersome as well.
A better solution is to directly highlight the error in the editor window
and move the focus there. The innermost line outside the system modules (in
my example, the only such line) is by far the best place to start. The
error message itself also needs to be displayed somewhere in that window.
It might then be best to limit the display in the output window to just
"AttributeError: position". The user can see the full call stack in the
debugger, which also gives them other context information, such as the
values of local variables. Our students will have the debugger disabled,
and won't see a call stack at all, which is fine because they will be
writing very "flat" programs.
We have encountered some other issues with error reporting. For example,
errors are incorrectly reported on the first line of some multi-line
expressions. However, discussing these would require concrete examples
which I don't have handy. I'll try to collect some and follow up later.
Dave
From guido@python.org Wed Mar 8 00:57:13 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 07 Mar 2000 19:57:13 -0500
Subject: [Idle-dev] What we need, and how we can help
In-Reply-To: Your message of "Tue, 07 Mar 2000 17:53:13 EST."
References:
Message-ID: <200003080057.TAA19277@eric.cnri.reston.va.us>
> Part of the problem here is something I mentioned before: the traceback
> extends both "upwards" into IDLE's code and "downwards" into a library that
> should be opaque to the programmer.
We intend to do this.
> Removing that part would yield just:
>
> |Traceback (innermost last):
> | File "C:\python\box.py", line 7, in ?
> | print s.posiiton
> |AttributeError: posiiton
>
> Then you can right-click on the 2nd line and choose "Go to file/line" from a
> context menu, at which point you see the code highlighted in your editor
> window. Unfortunately, there is nothing to suggest to the user that they
> can or should right-click on that particular line. This interface is also
> unlike anything students are likely to have seen before, and it's
> unnecessarily cumbersome as well.
Try enabling "auto-open stack viewer" in the debug menu. (This would
be better of course with the system parts of the traceback removed.)
This gives a BIG hint what to do! (And yes, it's still a prototype.
Suggestions are welcome. Note that you can edit variables here!
Eventually the stack view in the debugger should look the same.)
> A better solution is to directly highlight the error in the editor window
> and move the focus there. The innermost line outside the system modules (in
> my example, the only such line) is by far the best place to start. The
> error message itself also needs to be displayed somewhere in that window.
The logistics of this get tricky though... If you put the message in
the status bar, it isn't very obvious, and a dialog makes it hard to
correlate it to the source window.
> It might then be best to limit the display in the output window to just
> "AttributeError: position". The user can see the full call stack in the
> debugger, which also gives them other context information, such as the
> values of local variables. Our students will have the debugger disabled,
> and won't see a call stack at all, which is fine because they will be
> writing very "flat" programs.
>
> We have encountered some other issues with error reporting. For example,
> errors are incorrectly reported on the first line of some multi-line
> expressions. However, discussing these would require concrete examples
> which I don't have handy. I'll try to collect some and follow up later.
That would be great!
Unfortunately, for better diagnostics we may have to completely redo
the parser... So it will be an expensive project. But I agree it's
needed.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From jeremy@cnri.reston.va.us Wed Mar 8 03:16:01 2000
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Tue, 7 Mar 2000 22:16:01 -0500 (EST)
Subject: [Idle-dev] What we need, and how we can help
In-Reply-To: <200003080057.TAA19277@eric.cnri.reston.va.us>
References:
<200003080057.TAA19277@eric.cnri.reston.va.us>
Message-ID: <14533.50673.117369.178354@bitdiddle.cnri.reston.va.us>
>>>>> "GvR" == Guido van Rossum writes:
>> A better solution is to directly highlight the error in the
>> editor window and move the focus there. The innermost line
>> outside the system modules (in my example, the only such line) is
>> by far the best place to start. The error message itself also
>> needs to be displayed somewhere in that window.
GvR> The logistics of this get tricky though... If you put the
GvR> message in the status bar, it isn't very obvious, and a dialog
GvR> makes it hard to correlate it to the source window.
DrScheme uses hyperlinks for some similar cases. I found it quite
confusing at first, perhaps because I don't expect my IDE to have
hyperlinks. It seems, though, that it would be fairly transparent to
a new user, who is probably familiar with Web browsing.
Each filename/line number pair could be a link. The name of the
exception could also be a link to help/documentation on what it means.
Jeremy
From Albert.Brandl@edvg.co.at Wed Mar 8 09:22:40 2000
From: Albert.Brandl@edvg.co.at (Albert Brandl)
Date: Wed, 8 Mar 2000 10:22:40 +0100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
Message-ID:
>OK, here's a patch. It was remarkably simple.
Remarkable indeed!
>The following patch prevents all editing from having any effect before
>the "I/O mark" -- an invisible marker in the text that delineates the
>beginning of the command editing area, typically placed just after the
>last prompt. You can still steer the cursor anywhere in the window
>(unlike with a typical bash-in-an-xterm setup) but you can't type (or
>delete or cut or paste) when you're not in the command area.
>
>Please try this out, and let me know how it "feels"!
It already "feels" better, since it prevents most of the annoying errors
resulting from editing portions of the screen other than the command.
There are still some differences from the way shells usually behave.
Most importantly, I think that the arrow keys should be restricted
similar to the backspace key. They should only move around in the current
command and / or the command history (beware that multi-line commands need
some special care). It's e.g. strange to press Shift-Ctrl-A and see the
selection expand to the beginning of the line (including the Prompt).
I'd like to close with an unqualified remark on the class design:
On the long run, a seperate class for handling the user input might pay off.
It could be some kind of state machine with knowledge on the position of the
cursor, the bounds of the command line, the history and so on. This seems
more natural to me than intercepting the input and throwing it away under
certain circumstances. Furthermore, it would allow for easy adaption to
different preferences (e.g. vi-like vs. readline- or Emacs-like
"look-and-feel").
Of course, I have no idea if this idea fits into the concepts used so far.
If it does not, just forget about it ;-)
Yours,
Albert
From guido@python.org Wed Mar 8 11:52:30 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 08 Mar 2000 06:52:30 -0500
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: Your message of "Wed, 08 Mar 2000 10:22:40 +0100."
References:
Message-ID: <200003081152.GAA19914@eric.cnri.reston.va.us>
> On the long run, a seperate class for handling the user input might pay off.
> It could be some kind of state machine with knowledge on the position of the
> cursor, the bounds of the command line, the history and so on. This seems
> more natural to me than intercepting the input and throwing it away under
> certain circumstances. Furthermore, it would allow for easy adaption to
> different preferences (e.g. vi-like vs. readline- or Emacs-like
> "look-and-feel").
I agree that this would be better. It means however that we will have
to somehow unbind *all* Tk's default bindings for the text widget, and
provide replacement bindings. In the long run this may be our only
hope. Thanks for speaking up!
--Guido van Rossum (home page: http://www.python.org/~guido/)
From gritsch@iue.tuwien.ac.at Wed Mar 8 12:19:49 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Wed, 08 Mar 2000 13:19:49 +0100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
References: <200003081152.GAA19914@eric.cnri.reston.va.us>
Message-ID: <38C64565.83E7CFC3@iue.tuwien.ac.at>
Guido van Rossum wrote:
> > On the long run, a seperate class for handling the user input might pay off.
> > It could be some kind of state machine with knowledge on the position of the
> > cursor, the bounds of the command line, the history and so on. This seems
> > more natural to me than intercepting the input and throwing it away under
> > certain circumstances. Furthermore, it would allow for easy adaption to
> > different preferences (e.g. vi-like vs. readline- or Emacs-like
> > "look-and-feel").
>
> I agree that this would be better. It means however that we will have
> to somehow unbind *all* Tk's default bindings for the text widget, and
> provide replacement bindings. In the long run this may be our only
> hope. Thanks for speaking up!
Another approach maybe would be to add an additional layer between the
functonality you want to have and the Tk text widget. In such a design it would
be easier to change the underlying GUI toolkit to something else than Tk, in the
case that someone wants to port idle to this other toolkit, or for the case that
some other GUI toolkit evolves to become the defacto standard toolkit of Python.
--
Markus
From guido@python.org Wed Mar 8 14:11:49 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 08 Mar 2000 09:11:49 -0500
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: Your message of "Wed, 08 Mar 2000 13:19:49 +0100."
<38C64565.83E7CFC3@iue.tuwien.ac.at>
References: <200003081152.GAA19914@eric.cnri.reston.va.us>
<38C64565.83E7CFC3@iue.tuwien.ac.at>
Message-ID: <200003081411.JAA20057@eric.cnri.reston.va.us>
> Another approach maybe would be to add an additional layer between
> the functonality you want to have and the Tk text widget. In such a
> design it would be easier to change the underlying GUI toolkit to
> something else than Tk, in the case that someone wants to port idle
> to this other toolkit, or for the case that some other GUI toolkit
> evolves to become the defacto standard toolkit of Python.
This is a popular meme: introduce an extra abstraction layer to
isolate you from the GUI toolkit du jour. It has been hashed to death
many times in c.l.py and elsewhere -- there even was a SIG devoted to
GUIs that did nothing but discuss such designs.
It doesn't work very well, because typically, the GUI toolkit of
tomorrow contains features that aren't in the abstraction layer of
today, and in the mean time the abstraction layer is either
heavy-weight or lowest-common-denominator, and in both cases people
find ways around it out of necessity (performance or the desire to do
things "just like reall apps do").
--Guido van Rossum (home page: http://www.python.org/~guido/)
From faassen@vet.uu.nl Wed Mar 8 18:18:05 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Wed, 8 Mar 2000 19:18:05 +0100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <200003081411.JAA20057@eric.cnri.reston.va.us>
References: <200003081152.GAA19914@eric.cnri.reston.va.us> <38C64565.83E7CFC3@iue.tuwien.ac.at> <200003081411.JAA20057@eric.cnri.reston.va.us>
Message-ID: <20000308191805.A16466@vet.uu.nl>
Guido van Rossum wrote:
> > Another approach maybe would be to add an additional layer between
> > the functonality you want to have and the Tk text widget. In such a
> > design it would be easier to change the underlying GUI toolkit to
> > something else than Tk, in the case that someone wants to port idle
> > to this other toolkit, or for the case that some other GUI toolkit
> > evolves to become the defacto standard toolkit of Python.
>
> This is a popular meme: introduce an extra abstraction layer to
> isolate you from the GUI toolkit du jour. It has been hashed to death
> many times in c.l.py and elsewhere -- there even was a SIG devoted to
> GUIs that did nothing but discuss such designs.
The difference is that we're talking about a single application here,
and that was about a GUI abstraction layer. In fact, most GUI toolkits *are*
abstraction layers over the real GUI; Tk is, wxWindows is, GTK is and Qt is
too.
A GUI abstraction layer for a specific application is easier to do than a
general abstraction layer. This kind of abstraction is called
'View-Model-Controller', I thought.
> It doesn't work very well, because typically, the GUI toolkit of
> tomorrow contains features that aren't in the abstraction layer of
> today, and in the mean time the abstraction layer is either
> heavy-weight or lowest-common-denominator, and in both cases people
> find ways around it out of necessity (performance or the desire to do
> things "just like reall apps do").
That's true for the general abstraction layer, but for IDLE, we can of
course make our own fine tuned abstractions for whatever we want to do.
Lots the IDLE source of course is already like that, but it would be nice if
more was. I think with application specific GUI abstraction you can actually
exploit features on GUIs where they are avaible.
'highest-common-denominator' :)
Trying to abstract about the GUI for IDLE might make the design cleaner and
increase portability to other GUI toolkits. I'll admit that I have an
interest here; I think such portability would be very nice, especially for
environments like the KDE and Gnome desktops.
The other objection, that the system becomes too heavy weight, may or may
not go away if you do application specific GUI abstraction. I don't really
know enough about Tkinter to judge this.
Regards,
Martijn
From Fredrik Lundh" <200003081152.GAA19914@eric.cnri.reston.va.us> <38C64565.83E7CFC3@iue.tuwien.ac.at> <200003081411.JAA20057@eric.cnri.reston.va.us> <20000308191805.A16466@vet.uu.nl>
Message-ID: <01ab01bf8935$fb62ee60$34aab5d4@hagrid>
Martijn Faassen wrote:
> A GUI abstraction layer for a specific application is easier to do =
than a=20
> general abstraction layer. This kind of abstraction is called =
'View-Model-
> Controller', I thought.
in contrast to "Model-View-Controller", you mean? ;-)
fwiw, all Tkinter widgets use MVC -- but in most cases,
with a tight coupling between the model and the view.
in uiToolkit, we've made things more MVCish -- which
makes the toolkit more general [1], not less.
1) as in "not confined by specialization or careful limitation"
From faassen@vet.uu.nl Wed Mar 8 20:59:20 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Wed, 8 Mar 2000 21:59:20 +0100
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <01ab01bf8935$fb62ee60$34aab5d4@hagrid>
References: <200003081152.GAA19914@eric.cnri.reston.va.us> <38C64565.83E7CFC3@iue.tuwien.ac.at> <200003081411.JAA20057@eric.cnri.reston.va.us> <20000308191805.A16466@vet.uu.nl> <01ab01bf8935$fb62ee60$34aab5d4@hagrid>
Message-ID: <20000308215920.A17956@vet.uu.nl>
Fredrik Lundh wrote:
> Martijn Faassen wrote:
> > A GUI abstraction layer for a specific application is easier to do than a
> > general abstraction layer. This kind of abstraction is called 'View-Model-
> > Controller', I thought.
>
> in contrast to "Model-View-Controller", you mean? ;-)
I knew I was saying it the wrong way around. :)
> fwiw, all Tkinter widgets use MVC -- but in most cases,
> with a tight coupling between the model and the view.
> in uiToolkit, we've made things more MVCish -- which
> makes the toolkit more general [1], not less.
Cool. I should dive into Tkinter land sometime, I guess. :)
Regards,
Martijn
From tim_one@email.msn.com Thu Mar 9 03:53:04 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 8 Mar 2000 22:53:04 -0500
Subject: [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
In-Reply-To: <20000308191805.A16466@vet.uu.nl>
Message-ID: <000601bf897a$f8e47380$0d2d153f@tim>
[Martijn Faassen]
> ...
> That's true for the general abstraction layer, but for IDLE, we can of
> course make our own fine tuned abstractions for whatever we want to do.
Indeed, Mark Hammond & I invented the (ill-documented, alas) notion of a
"virtual text widget" for IDLE, one of whose key abstractions is a query
function answering "is this particular character absolutely positively
guaranteed not to be in the interior of a Python string?". Few GUI text
widgets answer that directly .
The motivation for this one is that auto-indent and paren-match (and "things
like that") need an absolutely reliable answer to that question, but it can
be unboundedly expensive to answer from scratch (in the extreme, it can
require reparsing the entire file!). The cool thing is that IDLE and
PythonWin both already know the answer, thanks to the work they already did
for syntax coloring. They do the latter in entirely different ways, but
given that any Python IDE will also do that in *some* way, assuming that
every "Python text widget" knows the answer makes good sense.
So that was a triumph. Here's a failure: another virtual text widget
method sets tab stops (for people insane enough to use hard tab characters
). It turns out that had to be hidden in IDLE (but not in PythonWin),
because the Tk text widget itself doesn't support hard tabs in the way
people expect them to work, and it would be an incredibly amount of work to
fake it.
lowest-common-denominator-will-often-win-in-the-end-ly y'rs - tim
From strang@NMR.MGH.Harvard.EDU Fri Mar 10 20:09:05 2000
From: strang@NMR.MGH.Harvard.EDU (Gary Strangman)
Date: Fri, 10 Mar 2000 15:09:05 -0500 (EST)
Subject: [Idle-dev] Idle startup & Config
Message-ID:
Hello,
I'm a long-time user of python, but just fired up IDLE for the first time.
Quite nice, I must say. I have a couple questions, however, if anyone has
a moment to help. (BTW, this is all on a WinNT4 (SP3) machine, using
the 1.5.2(final) installer, and saying Yes to Tcl/Tk installation).
1) My first attempts resulted in the following crash ...
d:\Program Files\Python\Tools\idle> python PyShell.py
Traceback (innermost last):
File "PyShell.py", line 633, in ?
main()
File "PyShell.py", line 612, in main
fixwordbreaks(root)
File "D:\PROGRA~1\Python\Tools\idle\EditorWindow.py", line 606, in fixwordbreaks
tk.call('tcl_wordBreakAfter', 'a b', 0) # make sure word.tcl is loaded
TclError: invalid command name "tcl_wordBreakAfter"
d:\Program Files\Python\Tools\idle>
It was a reliable crash, despite the fact that (a) I know my Tk/Tcl and
Tkinter work, (b) the relevant word.tcl file is indeed in the proper tcl
subdirectory (default location except on drive D, not C) and (c) the same
thing occurred when I did a complete uninstall and reinstall of python
1.5.2(final). When I edited PyShell.py to comment out the two
fixwordbreaks() lines, IDLE seemed to work fine (thereby establishing
(a)).
2) The next/previous history icommands (Alt-n/Alt-p, respectively)
produce a beep each time the key-combo is pressed. I quickly perused the
source for the cause of this (I found the noise tiresome), but was unable
to find one. I'd really like to remove the beep. Anyone have a hint?
Thanks ...
Gary
--------------------------------------------------------------
Gary Strangman, PhD | Neural Systems Group
Office: 617-724-0662 | Massachusetts General Hospital
Home: xxx-xxx-xxxx | 13th Street, Bldg 149, Room 9103
strang@nmr.mgh.harvard.edu | Charlestown, MA 02129
From tim_one@email.msn.com Sat Mar 11 20:30:03 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 11 Mar 2000 15:30:03 -0500
Subject: [Idle-dev] Idle startup & Config
In-Reply-To:
Message-ID: <000f01bf8b98$9532fda0$c72d153f@tim>
[Gary Strangman]
> I'm a long-time user of python, but just fired up IDLE for the first time.
> Quite nice, I must say. I have a couple questions, however, if anyone has
> a moment to help. (BTW, this is all on a WinNT4 (SP3) machine, using
> the 1.5.2(final) installer, and saying Yes to Tcl/Tk installation).
> ... [and various flaky stuff that looks like Tcl confusion] ...
Try doing
dir/s tk*.dll
and
dir/s tcl*.dll
from the root of every disk, and getting rid of any tcl or tk dll that isn't
where the Python installer put them. Almost every problem with Tcl/Tk is
caused by some other app leaving behind some Tcl/Tk DLL in one of the system
directories (don't *assume* this didn't happen! some apps do it without
telling you), and Tcl/Tk seems incapable of reporting mismatches except via
behaving in weird ways. BTW, I've never heard of the specific symptoms you
desribed (tcl_wordBreakAfter invalid, & random inappropriate beeping), but
with a bogus DLL in the mix it's simply unpredictable.
Once you get it working, go to
http://www.python.org/idle/
and pick up IDLE 0.5 -- it has many valuable improvements over the version
that shipped with 1.5.2 (note that IDLE is written in pure Python -- this is
a small download and does *not*, e.g., fiddle with the Tcl/Tk installation).
From dscherer@cmu.edu Mon Mar 13 17:50:27 2000
From: dscherer@cmu.edu (David Scherer)
Date: Mon, 13 Mar 2000 12:50:27 -0500
Subject: [Idle-dev] Remote execution for IDLE
Message-ID:
I've been working on a number of extensions and changes to IDLE, in support
of the goals I mentioned in a previous post. I would like to share what
I've done with this list, and ask for your comments.
A copy of IDLE including my changes is available at
http://cil.andrew.cmu.edu/projects/visual/XIDLE-2000-03-13.zip
IWFM on Windows and Linux.
I'd appreciate your thoughts on my changes to the interface and the
architecture for remote execution, as well as bug reports.
Changes:
1. I've added a new extension, ExecBinding, which serves the same purpose
as ScriptBinding, but:
a) Executes the program in a new process, communicating with it through a
remote method call protocol built on top of sockets. Even user programs
like "while 1: pass" can be reliably terminated or restarted, and IDLE
remains fully responsive while they are running. I have not implemented
debugging, but I have attempted to design with that in mind.
b) Displays the standard I/O of the program in a new window, which persists
for multiple runs of the same program. At the beginning of each run, the
window scrolls to hide the output of previous runs.
c) Saves all named buffers before running (to ensure that the source of all
modules is up to date)
d) Supports executing an unnamed buffer (through a temporary file)
e) Displays tracebacks with "system modules" excluded. For the moment,
modules outside the directory of the user program are considered system
modules.
2. I've reorganized the menus a bit, splitting the excessively large Edit
menu into Edit, Format, and Run.
3. I made the "Python Documentation" feature work on Windows, and bound it
to the F1 key.
4. IDLE will read files with any end-of-line convention ("\r\n" for
Windows, "\n" for UNIX, or "\r" for Macintosh). Files are always saved with
the native convention.
5. The need for a well-known socket for ExecBinding mandates that only one
instance of IDLE can be running on the system. Additional instances use a
"netscape --remote"-like mechanism to pass their command-line parameters to
the first instance, and then terminate.
6. Executed with no command line parameters, IDLE now loads a blank editor.
Opening a file into this or any other unnamed, empty buffer replaces that
window rather than opening a new one. The people who have tested my changes
have found this behavior much more convenient. (Probably startup behavior
should be configurable through config.txt).
7. idle.bat and idle.pyw have been fixed on Windows. idle.bat contained an
absolute pathname for the Python interpreter which is not guaranteed to
hold. I replaced idle.pyw with a copy of idle.py, which fixed some odd
problems.
Let me know what you think,
Dave
From Moshe Zadka Tue Mar 14 00:58:18 2000
From: Moshe Zadka (Moshe Zadka)
Date: Tue, 14 Mar 2000 02:58:18 +0200 (IST)
Subject: [Idle-dev] Remote execution for IDLE
In-Reply-To:
Message-ID:
On Mon, 13 Mar 2000, David Scherer wrote:
> 5. The need for a well-known socket for ExecBinding mandates that only one
> instance of IDLE can be running on the system. Additional instances use a
> "netscape --remote"-like mechanism to pass their command-line parameters to
> the first instance, and then terminate.
Hmmmmmm....this bothers me. What about 10 Linux users running IDLE
on a single machine through 10 X-Servers? Will they interfere with each
other?
Two solutions:
1. One IDLE per user: keep the portnumber in a file .idle-port in the
user's home
2. One IDLE per X-Server: keep the portnumber in a property on the rot
window.
Other then that, most of your changes look cool, and I'd love to see them
make their way into standard Python.
One question:
What protocol have you used for remote-method calls? A homebrew one, or
a well known one? Just idle curiousity.
--
Moshe Zadka .
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
From jeremy@cnri.reston.va.us Tue Mar 14 03:42:25 2000
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Mon, 13 Mar 2000 22:42:25 -0500 (EST)
Subject: [Idle-dev] Remote execution for IDLE
In-Reply-To:
References:
Message-ID: <14541.46369.772448.310031@goon.cnri.reston.va.us>
>>>>> "MZ" == Moshe Zadka writes:
MZ> On Mon, 13 Mar 2000, David Scherer wrote:
>> 5. The need for a well-known socket for ExecBinding mandates
>> that only one instance of IDLE can be running on the system.
>> Additional instances use a "netscape --remote"-like mechanism to
>> pass their command-line parameters to the first instance, and
>> then terminate.
MZ> Hmmmmmm....this bothers me. What about 10 Linux users running
MZ> IDLE on a single machine through 10 X-Servers? Will they
MZ> interfere with each other?
MZ> Two solutions:
MZ> 1. One IDLE per user: keep the portnumber in a file .idle-port
MZ> in the user's home 2. One IDLE per X-Server: keep the portnumber
MZ> in a property on the rot window.
I haven't looked at Dave's code closely yet, but I imagine that a
third alternative is to have each IDLE process start up its own
execution engine subprocesses. The port number can be chosen by the
parent process and passed to the child as an argument.
MZ> Other then that, most of your changes look cool, and I'd love to
MZ> see them make their way into standard Python.
Me too!
Jeremy
From dscherer@cmu.edu Tue Mar 14 03:24:04 2000
From: dscherer@cmu.edu (David Scherer)
Date: Mon, 13 Mar 2000 22:24:04 -0500
Subject: [Idle-dev] Remote execution for IDLE
In-Reply-To: <14541.46369.772448.310031@goon.cnri.reston.va.us>
Message-ID:
> I haven't looked at Dave's code closely yet, but I imagine that a
> third alternative is to have each IDLE process start up its own
> execution engine subprocesses. The port number can be chosen by the
> parent process and passed to the child as an argument.
This is clearly the best approach for the multi-user situation on Unix, and
quite easy to add to my code, though I don't have time to do it myself at
the moment. It has the added advantage of not depending on the availability
of a specific high port number :)
The main reason I chose a "well-known port" to begin with is that I wanted
proof-of-concept that command-line arguments are not necessary. I am
looking ahead to the Macintosh, where it is *not possible* to have more than
one process running from the same binary, and "command line arguments" don't
exist in the normal sense. The only way I know of to start the loader on
the Mac is to make a physical copy of the Python interpreter on disk, change
its signature, change the signature of loader.py to match, and then launch()
loader.py. And I thought having to call waitpid() on UNIX sucked...
Of course, MacPython is also only beginning to grow thread support, and has
a buggy Tkinter implementation, and we haven't even managed to build a
working _tkinter.slb to start hacking up :(
I note that having only one IDLE running per user is desirable in any case,
because it enables much smarter behavior (e.g. preventing conflicting edits
of the same file). Figuring out when to do the "remote" thing on UNIX might
be tricky, but at least on Windows I would like to protect the novice who
reasons that if they opened their first IDLE window by double-clicking the
IDLE icon, they should open a second window in the same way.
Dave
From dscherer@cmu.edu Tue Mar 14 03:38:47 2000
From: dscherer@cmu.edu (David Scherer)
Date: Mon, 13 Mar 2000 22:38:47 -0500
Subject: [Idle-dev] Remote execution for IDLE
In-Reply-To:
Message-ID:
> One question:
> What protocol have you used for remote-method calls? A homebrew one, or
> a well known one? Just idle curiousity.
Homebrew. Reinventing that particular wheel was a useful exercise for me;
I'm relatively new to Python and still exploring its strengths.
If anyone points out a better solution and a compelling reason to switch, I
won't object strenuously. I do suspect that some kind of "distributed
object" architecture is needed if things like a real debugger are to be
implemented in reasonable time. Worrying about protocol issues at the same
time as trying to design a usable debugger doesn't sound like a recipe for
success.
Dave
From Moshe Zadka Tue Mar 14 05:55:08 2000
From: Moshe Zadka (Moshe Zadka)
Date: Tue, 14 Mar 2000 07:55:08 +0200 (IST)
Subject: [Idle-dev] Remote execution for IDLE
In-Reply-To:
Message-ID:
On Mon, 13 Mar 2000, David Scherer wrote:
[A lot of things, end gave as one of the reasons for something]
> ...if they opened their first IDLE window by double-clicking the
> IDLE icon, they should open a second window in the same way.
Let me just note (again) that I found it is very hard to deal with IDLE's
one-editor-per-toplevel-window philosophy. If I have the time, I'd like to
add multiple-editors-per-toplevel-window, and have, like in EMACS (only
switching terms from EMACS to browser terminology) two different commands:
- Open Frame (add an editor widget to a window)
- Open Window (add a new toplevel window with an editor widget)
Err...three different commands:
- Add Buffer (add a new buffer to the list of currently open buffers,
hiding another buffer)
- Open Frame
- Open Window
Well, among the commands I want to add are:
- Switch Buffer
- Add Buffer
- Open Frame
- Open Window
So basically, the model is
-- lots of buffers, lots of windows, each window has lots of frames, and
each frame can hold any buffer, except that one buffer cannot be shared
among two frames.
But the most important one is frames.
However, since the LAF I really like is Gtk, I'd probably have to rewrite
IDLE in Gtk...well, something else to occupy my Copious Free Time(tm)
--
Moshe Zadka .
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
From Moshe Zadka Tue Mar 14 06:06:06 2000
From: Moshe Zadka (Moshe Zadka)
Date: Tue, 14 Mar 2000 08:06:06 +0200 (IST)
Subject: [Idle-dev] Remote execution for IDLE
In-Reply-To:
Message-ID:
On Mon, 13 Mar 2000, David Scherer wrote:
> > One question:
> > What protocol have you used for remote-method calls? A homebrew one, or
> > a well known one? Just idle curiousity.
>
> Homebrew. Reinventing that particular wheel was a useful exercise for me;
> I'm relatively new to Python and still exploring its strengths.
>
> If anyone points out a better solution and a compelling reason to switch, I
> won't object strenuously.
Secret Labs wrote the Python XML-RPC library (linked from www.xmlrpc.org).
XML-RPC is a cool protocol if you don't have too many expectations.
SOAP is a richer protocol, but currently there is no Python implementation
(though the effbot has spread the rumor that it is in the works)
> I do suspect that some kind of "distributed
> object" architecture is needed if things like a real debugger are to be
> implemented in reasonable time. Worrying about protocol issues at the same
> time as trying to design a usable debugger doesn't sound like a recipe for
> success.
Hence my allusion to XML-RPC, so you can implement your debugger. XML-RPC
is simple enough it can even be implemented in C in a reasonable amount
of time <0.5 wink>, but I haven't played as much as I'd like with
xmlrpclib.py...
(Anyway, using xmlrpclib in Python is a pretty good way to get Guido to
include it in the Python distribution <0.3 wink>)
remote-ly y'rs, Z.
--
Moshe Zadka .
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
From faassen@vet.uu.nl Tue Mar 14 13:48:57 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Tue, 14 Mar 2000 14:48:57 +0100
Subject: [Idle-dev] Remote executution for IDLE
In-Reply-To:
References:
Message-ID: <20000314144857.A25903@vet.uu.nl>
Moshe Zadka wrote:
> On Mon, 13 Mar 2000, David Scherer wrote:
[snip]
> > I do suspect that some kind of "distributed
> > object" architecture is needed if things like a real debugger are to be
> > implemented in reasonable time. Worrying about protocol issues at the same
> > time as trying to design a usable debugger doesn't sound like a recipe for
> > success.
>
> Hence my allusion to XML-RPC, so you can implement your debugger. XML-RPC
> is simple enough it can even be implemented in C in a reasonable amount
> of time <0.5 wink>, but I haven't played as much as I'd like with
> xmlrpclib.py...
DOPY is also quite neat:
http://www.users.cloud9.net/~proteus/dopy/welcome.html
I've connected a Python on Windows to one on Linux with DOPY when I was
doing some experiments thinking about a 'look over someone's shoulder'
facility for IDLE.
> (Anyway, using xmlrpclib in Python is a pretty good way to get Guido to
You mean in IDLE, don't you?
> include it in the Python distribution <0.3 wink>)
Regards,
Martijn
From bas@andrew.cmu.edu Tue Mar 14 21:35:58 2000
From: bas@andrew.cmu.edu (Bruce Sherwood)
Date: Tue, 14 Mar 2000 16:35:58 -0500
Subject: [Idle-dev] A satisfied user
Message-ID: <3863986514.953051758@MUON.PC.CC.CMU.EDU>
I've been using Dave Scherer's new version of IDLE, and I really like it.
To me the most important aspect is that its interactivity for whole
programs is very close to what the interactive interpreter provides for
single statements. I'll interject that as a Python novice I'm uncomfortable
using the interactive interpreter because I want to be able to work
incrementally, including correcting rather than re-creating statements in
the face of expected incorrect syntax. For a novice I believe it is
typically more appropriate to be working on and revising a program rather
than typing single lines. And beyond the novice level, it is really nice to
have high interactivity.
With the new IDLE, on Windows the single keypress F5 saves and runs, and
even aborts a current run and starts another, whether pressed in the source
file or in the stdout window. And I like the single continuous stdout, with
a header for each run and scrolling to the header on each run. And I like
the abbreviated error tracing, and the quick access from error to offending
line.
As far as the user interface goes, the only thing I can think of to raise
the interactivity even higher has to do with a detail of window focus. If I
click on a graphics output window to close it, I then have to click in the
source window to get focus there again. Could closing the graphics window
automatically restore focus to the source window that was last edited?
Bruce Sherwood
Carnegie Mellon University
From faassen@vet.uu.nl Tue Mar 14 22:02:16 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Tue, 14 Mar 2000 23:02:16 +0100
Subject: [Idle-dev] A satisfied user
In-Reply-To: <3863986514.953051758@MUON.PC.CC.CMU.EDU>
References: <3863986514.953051758@MUON.PC.CC.CMU.EDU>
Message-ID: <20000314230216.A26971@vet.uu.nl>
Bruce Sherwood wrote:
> I've been using Dave Scherer's new version of IDLE, and I really like it.
I just tried it and I agree it's nicer to work with than before, because
now I don't have to think about anything and just press F5. It comes
close to what Emacs Python-mode does.
One thing I've noticed is that when you manually close the output window
(under X) the program keeps running anyway. I think the system should
close the program down in that case, which is what I expected. Now I had
two programs running, one printing all integers up to infinity, and
another saving those integers to a file, and I'm not sure if there is
any way to close them under those circumstances.
Also I wonder why the current working directory is set to /var/tmp (I
don't know if this is new or was already a feature of IDLE). It's not the
directory I tend to go look in. It's hard to say what IDLE should do
under Linux anyway, though. Ah, I notice that when you actually open
a file in another directory, the working directory changes to that. Cool!
What I'd still like to do is open a file that doesn't exist yet, creating
it. At the moment I can't do "And there shall be a module, and I will name
thee foo.py", which is a bit frustrating.
> To me the most important aspect is that its interactivity for whole
> programs is very close to what the interactive interpreter provides for
> single statements. I'll interject that as a Python novice I'm uncomfortable
> using the interactive interpreter because I want to be able to work
> incrementally, including correcting rather than re-creating statements in
> the face of expected incorrect syntax. For a novice I believe it is
> typically more appropriate to be working on and revising a program rather
> than typing single lines. And beyond the novice level, it is really nice to
> have high interactivity.
I agree. I think I'll adopt this version for my Python class. :)
Regards,
Martijn
From Moshe Zadka Wed Mar 15 09:41:55 2000
From: Moshe Zadka (Moshe Zadka)
Date: Wed, 15 Mar 2000 11:41:55 +0200 (IST)
Subject: [Idle-dev] TreeWidget
Message-ID:
The TreeWidget module contains two parts:
- An absrtact interface for a tree node
- A Tk widget to use that interface
If those two parts were seperated, it would allow users of other Toolkit
to use that interface to display Python object trees
Changes needed:
-- Sperate TreeWidget into two modules
-- Modify ObjectBrowser into importing the Tk-specific part only in the
test function
-- Seperate ClassBrowser into two seperate modules, Tk-specific and
generic
-- Ditto for PathBrowser
(Random bonus: A PostScript output device wouldn't be too hard to attach
to that interface, and we'd have high-quality prinitng of class
hierarchies)
Any thoughts? I might try to do this over the weekend.
--
Moshe Zadka .
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
From dscherer@cmu.edu Wed Mar 15 15:12:56 2000
From: dscherer@cmu.edu (David Scherer)
Date: Wed, 15 Mar 2000 10:12:56 -0500
Subject: [Idle-dev] A satisfied user
In-Reply-To: <20000315113436.A27699@vet.uu.nl>
Message-ID:
> The key bindings on Unix are rather inconsistent, but the ones that are in
> these Idle now are even less so. Generally copy, cut and paste is
> either alt-C, alt-X and alt-V or ctrl-C, ctrl-X, ctrl-V. The
> desktop projects
> like Gnome and KDE seem to be moving towards the control combo.
>
> So perhaps Idle should move to that, and use something else for
> breaking the
> program. CTRL-A.
I think commenting on the selection of keys on UNIX invites religious wars,
so I'm going to stay out of it. Maybe more than one set of preferences is
needed (vi, Emacs, and as-close-to-Windows-as-possible :)
> Hm, perhaps I was mistaken in my observation then! I just experimented
> here, and the program seems to have termined just fine when I closed
> the window. I may be supplying you with false bug reports, ick. I
> think I based my observation on the idea that I wrote a loop like this:
>
> f = open("foo.txt", "w")
> i = 0
> while 1:
> f.write("%s\n" % i)
> print i
> i = i + 1
>
> Then I closed the window when the output was around ..I forget, but
> sub thousand, I think. I recall seeing 3 processes running. When
> I had killed
> IDLE however, I checked the file and it had a multiple thousand
> number in it at
> the end. When I just tried the same experiment, the last number
> in the file
> was a lot bigger than the last number I saw on the screen too, however, so
> it might've been my mistake. I assumed that having started 2 programs that
> ran infinitely, and having one IDLE open, I'd have 3 processes, but that
> was mistaken.
I think you are actually seeing "buffering" in the standard output. Your
program had probably actually gotten to i>2000, but IDLE hadn't received and
printed all of the numbers yet. If you had terminated the program with
"stop program" you would have seen all of that output appear, but since you
are closing the output window you never see it. Try a program that prints
to the screen only when (i%100)==0, or whatever.
It might be necessary to limit the amount of buffering that takes place, for
this reason. There may be a performance hit, though.
Dave
From faassen@vet.uu.nl Wed Mar 15 19:13:01 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Wed, 15 Mar 2000 20:13:01 +0100
Subject: [Idle-dev] TreeWidget
In-Reply-To:
References:
Message-ID: <20000315201301.A28374@vet.uu.nl>
Moshe Zadka wrote:
[snip MVC in action]
> (Random bonus: A PostScript output device wouldn't be too hard to attach
> to that interface, and we'd have high-quality prinitng of class
> hierarchies)
Have you tried Dia? It's this really nice GTK based diagramming tool
that can be used to create UML diagrams. It would be nice if IDLE
somehow had support for those too. You'd have high-quality printing
and editing support for UML. :)
Regards,
Martijn
From dscherer@cmu.edu Wed Mar 15 19:32:35 2000
From: dscherer@cmu.edu (David Scherer)
Date: Wed, 15 Mar 2000 14:32:35 -0500
Subject: [Idle-dev] TreeWidget
In-Reply-To:
Message-ID:
Moshe Zadka wrote:
> The TreeWidget module contains two parts:
>
> - An absrtact interface for a tree node
> - A Tk widget to use that interface
>
> If those two parts were seperated, it would allow users of other Toolkit
> to use that interface to display Python object trees
It would also allow users of Tk to use the tree widget for other purposes.
I needed a tree widget to experiment with dynamic inspection at one point,
and at the time I didn't know of the tree widget in IDLE, so I ended up
using one from vex.net/parnassus, which was rather inferior to the one IDLE
uses.
Dave
From guido@python.org Fri Mar 17 21:45:36 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 17 Mar 2000 16:45:36 -0500
Subject: [Idle-dev] Window focus (was: A satisfied user)
In-Reply-To: Your message of "Tue, 14 Mar 2000 16:35:58 EST."
<3863986514.953051758@MUON.PC.CC.CMU.EDU>
References: <3863986514.953051758@MUON.PC.CC.CMU.EDU>
Message-ID: <200003172145.QAA12228@eric.cnri.reston.va.us>
> As far as the user interface goes, the only thing I can think of to raise
> the interactivity even higher has to do with a detail of window focus. If I
> click on a graphics output window to close it, I then have to click in the
> source window to get focus there again. Could closing the graphics window
> automatically restore focus to the source window that was last edited?
I believe that this particular behavior is a (mis)feature of the
Windows desktop, not of IDLE (or even of Tkinter). In my experience
it's pretty random whether closing a window activates the window below
it or not... IDLE itself has no data structure that manages the stack
of open windows (which may include windows owned by other apps
anyway).
Sorry to disappoint,
--Guido van Rossum (home page: http://www.python.org/~guido/)
From dscherer@cmu.edu Fri Mar 17 22:14:30 2000
From: dscherer@cmu.edu (David Scherer)
Date: Fri, 17 Mar 2000 17:14:30 -0500
Subject: [Idle-dev] Window focus (was: A satisfied user)
In-Reply-To: <200003172145.QAA12228@eric.cnri.reston.va.us>
Message-ID:
Bruce wrote:
> As far as the user interface goes, the only thing I can think of to raise
> the interactivity even higher has to do with a detail of window focus. If
I
> click on a graphics output window to close it, I then have to click in the
> source window to get focus there again. Could closing the graphics window
> automatically restore focus to the source window that was last edited?
Guido responded:
> I believe that this particular behavior is a (mis)feature of the
> Windows desktop, not of IDLE (or even of Tkinter). In my experience
> it's pretty random whether closing a window activates the window below
> it or not... IDLE itself has no data structure that manages the stack
> of open windows (which may include windows owned by other apps
> anyway).
In this particular case, it is possible for IDLE to find out that the window
has closed, because the user program terminates and disconnects. It might
make sense for it to explicitly set the focus to the editor window when this
happens.
Unfortunately, I don't know of a way for an application to claim the focus,
or raise its windows above another application's using Tkinter, even though
that much is possible on Windows. Calling editwin.wakeup() will raise
editwin above other windows in IDLE, and give it focus if the focus belongs
to IDLE generally, but it won't help when (for example) the desktop or the
taskbar has the focus.
Does anyone know of a simple solution to that problem?
Dave
From barmeier@BARMEIER.COM Mon Mar 20 08:03:02 2000
From: barmeier@BARMEIER.COM (Matthias Barmeier)
Date: Mon, 20 Mar 2000 09:03:02 +0100
Subject: AW: AW: AW: [Idle-dev] Extends an events
In-Reply-To: <200003051227.HAA05425@eric.cnri.reston.va.us>
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01BF924B.18F7D1C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Hi,
its me again. Of course it takes more than one or two hours but I think it
functional
enough to present an intermediate state.
I have marked the codes I have chenged with ### M.Barmeier.
Copy the attached files to your idel-develeopment directory and start idle.
Everything should work like before. If you open a file you see a message in
your console window
where the opened filename is displayed. This message is printed from the
extension RecentList.py.
This is for discussion only!!! Dont use it in any productive environment !!!
So what do you think ??
/*
Dipl.-Inform. Matthias Barmeier Tel: +49 (0)30 79 70 72 87
Büro für Softwareentwicklung Fax +49 (0)30 79 70 72 88
Grunewaldstr. 18 Email: barmeier@barmeier.com
12165 Berlin WWW:
*/
> -----Ursprüngliche Nachricht-----
> Von: guido@CNRI.Reston.VA.US [mailto:guido@CNRI.Reston.VA.US]Im Auftrag
> von Guido van Rossum
> Gesendet: Sonntag, 5. März 2000 13:28
> An: Matthias Barmeier
> Cc: idle-dev@python.org
> Betreff: Re: AW: AW: [Idle-dev] Extends an events
>
>
> > I have checked the Tcl/Tk bind and bindings. But as I can see
> > parameter passing is impossible when using this approach.
>
> In the rare cases where you need to pass parameters around, you can
> place them on the EditorWindow (or whatever) instance. This can
> simply be part of the specs of a particular binding (e.g. open).
>
> > When I find an hour or two in the next week I will try to make a
> > suggestion in form of a modified EditorWindow.py.
>
> Great!
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
------=_NextPart_000_0000_01BF924B.18F7D1C0
Content-Type: text/plain;
name="IOBinding.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="IOBinding.py"
import os
import tkFileDialog
import tkMessageBox
#$ event <>
#$ win
#$ unix
#$ event <>
#$ win
#$ unix
#$ event <>
#$ win
#$ unix
#$ event <>
#$ win
#$ unix
class IOBinding:
def __init__(self, editwin):
self.editwin =3D editwin
self.text =3D editwin.text
### M.BArmeier =20
self.editwin.eventmanager.registerDefaultCallback (self.text, =
"<>", self.open)
self.editwin.eventmanager.registerDefaultCallback (self.text, =
"<>", self.save)
self.editwin.eventmanager.registerDefaultCallback (self.text, =
"<>", self.save_as)
self.editwin.eventmanager.registerDefaultCallback (self.text, =
"<>", self.save_a_copy)
### --
def close(self):
### M.BArmeier =20
=
self.editwin.eventmanager.unregisterDefaultCallback("<>")
=
self.editwin.eventmanager.unregisterDefaultCallback("<>")
=
self.editwin.eventmanager.unregisterDefaultCallback("<>")
=
self.editwin.eventmanager.unregisterDefaultCallback("<>")
### --
# Break cycles
self.editwin =3D None
self.text =3D None
self.filename_change_hook =3D None
def get_saved(self):
return self.editwin.get_saved()
def set_saved(self, flag):
self.editwin.set_saved(flag)
def reset_undo(self):
self.editwin.reset_undo()
filename_change_hook =3D None
def set_filename_change_hook(self, hook):
self.filename_change_hook =3D hook
filename =3D None
def set_filename(self, filename):
self.filename =3D filename
self.set_saved(1)
if self.filename_change_hook:
self.filename_change_hook()
def open(self, event):
if self.editwin.flist:
filename =3D self.askopenfile()
if filename:
self.editwin.flist.open(filename)
### M.Barmeier
event["FileName"]=3Dfilename
### --
else:
self.text.focus_set()
### M.Barmeier
return event
### --
# Code for use outside IDLE:
if self.get_saved():
reply =3D self.maybesave()
if reply =3D=3D "cancel":
self.text.focus_set()
return "break"
filename =3D self.askopenfile()
if filename:
self.loadfile(filename)
else:
self.text.focus_set()
return "break"
def loadfile(self, filename):
try:
f =3D open(filename)
chars =3D f.read()
f.close()
except IOError, msg:
tkMessageBox.showerror("I/O Error", str(msg), =
master=3Dself.text)
return 0
self.text.delete("1.0", "end")
self.set_filename(None)
self.text.insert("1.0", chars)
self.reset_undo()
self.set_filename(filename)
self.text.mark_set("insert", "1.0")
self.text.see("insert")
return 1
def maybesave(self):
if self.get_saved():
return "yes"
message =3D "Do you want to save %s before closing?" % (
self.filename or "this untitled document")
m =3D tkMessageBox.Message(
title=3D"Save On Close",
message=3Dmessage,
icon=3DtkMessageBox.QUESTION,
type=3DtkMessageBox.YESNOCANCEL,
master=3Dself.text)
reply =3D m.show()
if reply =3D=3D "yes":
self.save(None)
if not self.get_saved():
reply =3D "cancel"
self.text.focus_set()
return reply
def save(self, event):
if not self.filename:
self.save_as(event)
else:
if self.writefile(self.filename):
self.set_saved(1)
self.text.focus_set()
return "break"
def save_as(self, event):
filename =3D self.asksavefile()
if filename:
if self.writefile(filename):
self.set_filename(filename)
self.set_saved(1)
self.text.focus_set()
return "break"
def save_a_copy(self, event):
filename =3D self.asksavefile()
if filename:
self.writefile(filename)
self.text.focus_set()
return "break"
def writefile(self, filename):
self.fixlastline()
try:
f =3D open(filename, "w")
chars =3D self.text.get("1.0", "end-1c")
f.write(chars)
f.close()
## print "saved to", `filename`
return 1
except IOError, msg:
tkMessageBox.showerror("I/O Error", str(msg),
master=3Dself.text)
return 0
def fixlastline(self):
c =3D self.text.get("end-2c")
if c !=3D '\n':
self.text.insert("end-1c", "\n")
opendialog =3D None
savedialog =3D None
filetypes =3D [
("Python and text files", "*.py *.pyw *.txt", "TEXT"),
("All text files", "*", "TEXT"),
("All files", "*"),
]
def askopenfile(self):
dir, base =3D self.defaultfilename("open")
if not self.opendialog:
self.opendialog =3D tkFileDialog.Open(master=3Dself.text,
=
filetypes=3Dself.filetypes)
return self.opendialog.show(initialdir=3Ddir, =
initialfile=3Dbase)
def defaultfilename(self, mode=3D"open"):
if self.filename:
return os.path.split(self.filename)
else:
try:
pwd =3D os.getcwd()
except os.error:
pwd =3D ""
return pwd, ""
def asksavefile(self):
dir, base =3D self.defaultfilename("save")
if not self.savedialog:
self.savedialog =3D tkFileDialog.SaveAs(master=3Dself.text,
=
filetypes=3Dself.filetypes)
return self.savedialog.show(initialdir=3Ddir, =
initialfile=3Dbase)
def test():
from Tkinter import *
root =3D Tk()
class MyEditWin:
def __init__(self, text):
self.text =3D text
self.flist =3D None
self.text.bind("", self.open)
self.text.bind("", self.save)
self.text.bind("", self.save_as)
self.text.bind("", self.save_a_copy)
def get_saved(self): return 0
def set_saved(self, flag): pass
def reset_undo(self): pass
def open(self, event):
self.text.event_generate("<>")
def save(self, event):
self.text.event_generate("<>")
def save_as(self, event):
self.text.event_generate("<>")
def save_a_copy(self, event):
self.text.event_generate("<>")
text =3D Text(root)
text.pack()
text.focus_set()
editwin =3D MyEditWin(text)
io =3D IOBinding(editwin)
root.mainloop()
if __name__ =3D=3D "__main__":
test()
------=_NextPart_000_0000_01BF924B.18F7D1C0
Content-Type: text/plain;
name="RecentList.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="RecentList.py"
# Sample extension: zoom a window to maximum height
import re
import sys
class RecentList:
def __init__(self, editwin):
self.editwin =3D editwin
self.editwin.eventmanager.registerAfterCallback =
("<>", self.recentlist)
def recentlist (self, event):
print "open Completed for file ["+event["FileName"]+"]"
------=_NextPart_000_0000_01BF924B.18F7D1C0
Content-Type: text/plain;
name="EditorWindow.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="EditorWindow.py"
import sys
import os
import string
import re
import imp
from Tkinter import *
import tkSimpleDialog
import tkMessageBox
import idlever
import WindowList
### M.Barmeier
from EventManager import *
### --
# The default tab setting for a Text widget, in average-width =
characters.
TK_TABWIDTH_DEFAULT =3D 8
# File menu
#$ event <>
#$ win
#$ unix
#$ event <>
#$ win
#$ unix
#$ event <>
#$ event <>
#$ unix
#$ unix
#$ win
# Edit menu
#$ event <>
#$ win
#$ unix
#$ event <>
#$ win
#$ unix
#$ event <>
#$ win
#$ unix
#$ event <>
#$ win
#$ unix
# Help menu
#$ event <>
#$ win
#$ unix
#$ event <>
# Events without menu entries
#$ event <>
#$ win
#$ event <>
#$ win
#$ unix
#$ event <>
#$ unix
about_title =3D "About IDLE"
about_text =3D """\
IDLE %s
An Integrated DeveLopment Environment for Python
by Guido van Rossum
""" % idlever.IDLE_VERSION
class EditorWindow:
from Percolator import Percolator
from ColorDelegator import ColorDelegator
from UndoDelegator import UndoDelegator
from IOBinding import IOBinding
import Bindings
from Tkinter import Toplevel
from MultiStatusBar import MultiStatusBar
about_title =3D about_title
about_text =3D about_text
vars =3D {}
def __init__(self, flist=3DNone, filename=3DNone, key=3DNone, =
root=3DNone):
### M.Barmeier
self.eventmanager =3D EventManager()
### --
cprefs =3D self.ColorDelegator.cprefs
self.flist =3D flist
root =3D root or flist.root
self.root =3D root
if flist:
self.vars =3D flist.vars
self.menubar =3D Menu(root)
self.top =3D top =3D self.Toplevel(root, menu=3Dself.menubar)
self.vbar =3D vbar =3D Scrollbar(top, name=3D'vbar')
self.text_frame =3D text_frame =3D Frame(top)
self.text =3D text =3D Text(text_frame, name=3D'text', padx=3D5,
foreground=3Dcprefs.CNormal[0],
background=3Dcprefs.CNormal[1],
highlightcolor=3Dcprefs.CHilite[0],
highlightbackground=3Dcprefs.CHilite[1],
insertbackground=3Dcprefs.CCursor[1],
wrap=3D"none")
self.createmenubar()
self.apply_bindings()
self.top.protocol("WM_DELETE_WINDOW", self.close)
self.top.bind("<>", self.close_event)
### M.Barmeier
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.center_insert_event)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.help_dialog)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.python_docs)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.about_dialog)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.open_module)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", lambda event: "break")
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.select_all)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.remove_selection)
self.eventmanager.registerDefaultCallback (self.text, "<3>", =
self.right_menu_event)
if flist:
flist.inversedict[self] =3D key
if key:
flist.dict[key] =3D self
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.flist.new_callback)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.flist.close_all_callback)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.open_class_browser)
self.eventmanager.registerDefaultCallback (self.text, =
"<>", self.open_path_browser)
### --
vbar['command'] =3D text.yview
vbar.pack(side=3DRIGHT, fill=3DY)
text['yscrollcommand'] =3D vbar.set
if sys.platform[:3] =3D=3D 'win':
text['font'] =3D ("lucida console", 8)
# text['font'] =3D ("courier new", 10)
text_frame.pack(side=3DLEFT, fill=3DBOTH, expand=3D1)
text.pack(side=3DTOP, fill=3DBOTH, expand=3D1)
text.focus_set()
self.per =3D per =3D self.Percolator(text)
if self.ispythonsource(filename):
self.color =3D color =3D self.ColorDelegator(); =
per.insertfilter(color)
##print "Initial colorizer"
else:
##print "No initial colorizer"
self.color =3D None
self.undo =3D undo =3D self.UndoDelegator(); =
per.insertfilter(undo)
self.io =3D io =3D self.IOBinding(self)
text.undo_block_start =3D undo.undo_block_start
text.undo_block_stop =3D undo.undo_block_stop
undo.set_saved_change_hook(self.saved_change_hook)
io.set_filename_change_hook(self.filename_change_hook)
if filename:
if os.path.exists(filename):
io.loadfile(filename)
else:
io.set_filename(filename)
self.saved_change_hook()
self.load_extensions()
menu =3D self.menudict.get('windows')
if menu:
end =3D menu.index("end")
if end is None:
end =3D -1
if end >=3D 0:
menu.add_separator()
end =3D end + 1
self.wmenu_end =3D end
WindowList.register_callback(self.postwindowsmenu)
# Some abstractions so IDLE extensions are cross-IDE
self.askyesno =3D tkMessageBox.askyesno
self.askinteger =3D tkSimpleDialog.askinteger
self.showerror =3D tkMessageBox.showerror
if self.extensions.has_key('AutoIndent'):
self.extensions['AutoIndent'].set_indentation_params(
self.ispythonsource(filename))
self.set_status_bar()
def set_status_bar(self):
self.status_bar =3D self.MultiStatusBar(self.text_frame)
self.status_bar.set_label('column', 'Col: ?', side=3DRIGHT)
self.status_bar.set_label('line', 'Ln: ?', side=3DRIGHT)
self.status_bar.pack(side=3DBOTTOM, fill=3DX)
self.text.bind('', self.set_line_and_column)
self.text.bind('', self.set_line_and_column)
self.text.after_idle(self.set_line_and_column)
def set_line_and_column(self, event=3DNone):
line, column =3D string.split(self.text.index(INSERT), '.')
self.status_bar.set_label('column', 'Col: %s' % column)
self.status_bar.set_label('line', 'Ln: %s' % line)
def wakeup(self):
if self.top.wm_state() =3D=3D "iconic":
self.top.wm_deiconify()
else:
self.top.tkraise()
self.text.focus_set()
menu_specs =3D [
("file", "_File"),
("edit", "_Edit"),
("windows", "_Windows"),
("help", "_Help"),
]
def createmenubar(self):
mbar =3D self.menubar
self.menudict =3D menudict =3D {}
for name, label in self.menu_specs:
underline, label =3D prepstr(label)
menudict[name] =3D menu =3D Menu(mbar, name=3Dname)
mbar.add_cascade(label=3Dlabel, menu=3Dmenu, =
underline=3Dunderline)
self.fill_menus()
def postwindowsmenu(self):
# Only called when Windows menu exists
# XXX Actually, this Just-In-Time updating interferes badly
# XXX with the tear-off feature. It would be better to update
# XXX all Windows menus whenever the list of windows changes.
menu =3D self.menudict['windows']
end =3D menu.index("end")
if end is None:
end =3D -1
if end > self.wmenu_end:
menu.delete(self.wmenu_end+1, end)
WindowList.add_windows_to_menu(menu)
rmenu =3D None
def right_menu_event(self, event):
self.text.tag_remove("sel", "1.0", "end")
self.text.mark_set("insert", "@%d,%d" % (event.x, event.y))
if not self.rmenu:
self.make_rmenu()
rmenu =3D self.rmenu
self.event =3D event
iswin =3D sys.platform[:3] =3D=3D 'win'
if iswin:
self.text.config(cursor=3D"arrow")
rmenu.tk_popup(event.x_root, event.y_root)
if iswin:
self.text.config(cursor=3D"ibeam")
rmenu_specs =3D [
# ("Label", "<>"), ...
("Close", "<>"), # Example
]
def make_rmenu(self):
rmenu =3D Menu(self.text, tearoff=3D0)
for label, eventname in self.rmenu_specs:
def command(text=3Dself.text, eventname=3Deventname):
text.event_generate(eventname)
rmenu.add_command(label=3Dlabel, command=3Dcommand)
self.rmenu =3D rmenu
def about_dialog(self, event=3DNone):
tkMessageBox.showinfo(self.about_title, self.about_text,
master=3Dself.text)
helpfile =3D "help.txt"
def help_dialog(self, event=3DNone):
try:
helpfile =3D os.path.join(os.path.dirname(__file__), =
self.helpfile)
except NameError:
helpfile =3D self.helpfile
if self.flist:
self.flist.open(helpfile)
else:
self.io.loadfile(helpfile)
# XXX Fix these for Windows
help_viewer =3D "netscape -remote 'openurl(%(url)s)' 2>/dev/null || =
" \
"netscape %(url)s &"
help_url =3D "http://www.python.org/doc/current/"
def python_docs(self, event=3DNone):
cmd =3D self.help_viewer % {"url": self.help_url}
os.system(cmd)
def select_all(self, event=3DNone):
self.text.tag_add("sel", "1.0", "end-1c")
self.text.mark_set("insert", "1.0")
self.text.see("insert")
return "break"
def remove_selection(self, event=3DNone):
self.text.tag_remove("sel", "1.0", "end")
self.text.see("insert")
def open_module(self, event=3DNone):
# XXX Shouldn't this be in IOBinding or in FileList?
try:
name =3D self.text.get("sel.first", "sel.last")
except TclError:
name =3D ""
else:
name =3D string.strip(name)
if not name:
name =3D tkSimpleDialog.askstring("Module",
"Enter the name of a Python module\n"
"to search on sys.path and open:",
parent=3Dself.text)
if name:
name =3D string.strip(name)
if not name:
return
# XXX Ought to support package syntax
# XXX Ought to insert current file's directory in front of path
try:
(f, file, (suffix, mode, type)) =3D imp.find_module(name)
except (NameError, ImportError), msg:
tkMessageBox.showerror("Import error", str(msg), =
parent=3Dself.text)
return
if type !=3D imp.PY_SOURCE:
tkMessageBox.showerror("Unsupported type",
"%s is not a source module" % name, parent=3Dself.text)
return
if f:
f.close()
if self.flist:
self.flist.open(file)
else:
self.io.loadfile(file)
def open_class_browser(self, event=3DNone):
filename =3D self.io.filename
if not filename:
tkMessageBox.showerror(
"No filename",
"This buffer has no associated filename",
master=3Dself.text)
self.text.focus_set()
return None
head, tail =3D os.path.split(filename)
base, ext =3D os.path.splitext(tail)
import ClassBrowser
ClassBrowser.ClassBrowser(self.flist, base, [head])
def open_path_browser(self, event=3DNone):
import PathBrowser
PathBrowser.PathBrowser(self.flist)
def gotoline(self, lineno):
if lineno is not None and lineno > 0:
self.text.mark_set("insert", "%d.0" % lineno)
self.text.tag_remove("sel", "1.0", "end")
self.text.tag_add("sel", "insert", "insert +1l")
self.center()
def ispythonsource(self, filename):
if not filename:
return 1
base, ext =3D os.path.splitext(os.path.basename(filename))
if os.path.normcase(ext) in (".py", ".pyw"):
return 1
try:
f =3D open(filename)
line =3D f.readline()
f.close()
except IOError:
return 0
return line[:2] =3D=3D '#!' and string.find(line, 'python') >=3D =
0
def close_hook(self):
if self.flist:
self.flist.close_edit(self)
def set_close_hook(self, close_hook):
self.close_hook =3D close_hook
def filename_change_hook(self):
if self.flist:
self.flist.filename_changed_edit(self)
self.saved_change_hook()
if self.ispythonsource(self.io.filename):
self.addcolorizer()
else:
self.rmcolorizer()
def addcolorizer(self):
if self.color:
return
##print "Add colorizer"
self.per.removefilter(self.undo)
self.color =3D self.ColorDelegator()
self.per.insertfilter(self.color)
self.per.insertfilter(self.undo)
def rmcolorizer(self):
if not self.color:
return
##print "Remove colorizer"
self.per.removefilter(self.undo)
self.per.removefilter(self.color)
self.color =3D None
self.per.insertfilter(self.undo)
def saved_change_hook(self):
short =3D self.short_title()
long =3D self.long_title()
if short and long:
title =3D short + " - " + long
elif short:
title =3D short
elif long:
title =3D long
else:
title =3D "Untitled"
icon =3D short or long or title
if not self.get_saved():
title =3D "*%s*" % title
icon =3D "*%s" % icon
self.top.wm_title(title)
self.top.wm_iconname(icon)
def get_saved(self):
return self.undo.get_saved()
def set_saved(self, flag):
self.undo.set_saved(flag)
def reset_undo(self):
self.undo.reset_undo()
def short_title(self):
filename =3D self.io.filename
if filename:
filename =3D os.path.basename(filename)
return filename
def long_title(self):
return self.io.filename or ""
def center_insert_event(self, event):
self.center()
def center(self, mark=3D"insert"):
text =3D self.text
top, bot =3D self.getwindowlines()
lineno =3D self.getlineno(mark)
height =3D bot - top
newtop =3D max(1, lineno - height/2)
text.yview(float(newtop))
def getwindowlines(self):
text =3D self.text
top =3D self.getlineno("@0,0")
bot =3D self.getlineno("@0,65535")
if top =3D=3D bot and text.winfo_height() =3D=3D 1:
# Geometry manager hasn't run yet
height =3D int(text['height'])
bot =3D top + height - 1
return top, bot
def getlineno(self, mark=3D"insert"):
text =3D self.text
return int(float(text.index(mark)))
def close_event(self, event):
self.close()
def maybesave(self):
if self.io:
return self.io.maybesave()
def close(self):
self.top.wm_deiconify()
self.top.tkraise()
reply =3D self.maybesave()
if reply !=3D "cancel":
self._close()
return reply
def _close(self):
WindowList.unregister_callback(self.postwindowsmenu)
if self.close_hook:
self.close_hook()
self.flist =3D None
colorizing =3D 0
self.unload_extensions()
self.io.close(); self.io =3D None
self.undo =3D None # XXX
if self.color:
colorizing =3D self.color.colorizing
doh =3D colorizing and self.top
self.color.close(doh) # Cancel colorization
self.text =3D None
self.vars =3D None
self.per.close(); self.per =3D None
if not colorizing:
self.top.destroy()
def load_extensions(self):
self.extensions =3D {}
self.load_standard_extensions()
def unload_extensions(self):
for ins in self.extensions.values():
if hasattr(ins, "close"):
ins.close()
self.extensions =3D {}
def load_standard_extensions(self):
for name in self.get_standard_extension_names():
try:
self.load_extension(name)
except:
print "Failed to load extension", `name`
import traceback
traceback.print_exc()
def get_standard_extension_names(self):
import extend
return extend.standard
def load_extension(self, name):
mod =3D __import__(name, globals(), locals(), [])
cls =3D getattr(mod, name)
ins =3D cls(self)
self.extensions[name] =3D ins
kdnames =3D ["keydefs"]
if sys.platform =3D=3D 'win32':
kdnames.append("windows_keydefs")
elif sys.platform =3D=3D 'mac':
kdnames.append("mac_keydefs")
else:
kdnames.append("unix_keydefs")
keydefs =3D {}
for kdname in kdnames:
if hasattr(ins, kdname):
keydefs.update(getattr(ins, kdname))
if keydefs:
self.apply_bindings(keydefs)
for vevent in keydefs.keys():
methodname =3D string.replace(vevent, "-", "_")
while methodname[:1] =3D=3D '<':
methodname =3D methodname[1:]
while methodname[-1:] =3D=3D '>':
methodname =3D methodname[:-1]
methodname =3D methodname + "_event"
if hasattr(ins, methodname):
self.text.bind(vevent, getattr(ins, methodname))
if hasattr(ins, "menudefs"):
self.fill_menus(ins.menudefs, keydefs)
return ins
def apply_bindings(self, keydefs=3DNone):
if keydefs is None:
keydefs =3D self.Bindings.default_keydefs
text =3D self.text
text.keydefs =3D keydefs
for event, keylist in keydefs.items():
if keylist:
apply(text.event_add, (event,) + tuple(keylist))
def fill_menus(self, defs=3DNone, keydefs=3DNone):
# Fill the menus. Menus that are absent or None in
# self.menudict are ignored.
if defs is None:
defs =3D self.Bindings.menudefs
if keydefs is None:
keydefs =3D self.Bindings.default_keydefs
menudict =3D self.menudict
text =3D self.text
for mname, itemlist in defs:
menu =3D menudict.get(mname)
if not menu:
continue
for item in itemlist:
if not item:
menu.add_separator()
else:
label, event =3D item
checkbutton =3D (label[:1] =3D=3D '!')
if checkbutton:
label =3D label[1:]
underline, label =3D prepstr(label)
accelerator =3D get_accelerator(keydefs, event)
## strange function !
def command(text=3Dtext, event=3Devent):
text.event_generate(event)
if checkbutton:
var =3D self.getrawvar(event, BooleanVar)
menu.add_checkbutton(label=3Dlabel, =
underline=3Dunderline,
command=3Dcommand, =
accelerator=3Daccelerator,
variable=3Dvar)
else:
menu.add_command(label=3Dlabel, =
underline=3Dunderline,
command=3Dcommand, =
accelerator=3Daccelerator)
def getvar(self, name):
var =3D self.getrawvar(name)
if var:
return var.get()
def setvar(self, name, value, vartype=3DNone):
var =3D self.getrawvar(name, vartype)
if var:
var.set(value)
def getrawvar(self, name, vartype=3DNone):
var =3D self.vars.get(name)
if not var and vartype:
self.vars[name] =3D var =3D vartype(self.text)
return var
# Tk implementations of "virtual text methods" -- each platform
# reusing IDLE's support code needs to define these for its GUI's
# flavor of widget.
# Is character at text_index in a Python string? Return 0 for
# "guaranteed no", true for anything else. This info is expensive
# to compute ab initio, but is probably already known by the
# platform's colorizer.
def is_char_in_string(self, text_index):
if self.color:
# Return true iff colorizer hasn't (re)gotten this far
# yet, or the character is tagged as being in a string
return self.text.tag_prevrange("TODO", text_index) or \
"STRING" in self.text.tag_names(text_index)
else:
# The colorizer is missing: assume the worst
return 1
# If a selection is defined in the text widget, return (start,
# end) as Tkinter text indices, otherwise return (None, None)
def get_selection_indices(self):
try:
first =3D self.text.index("sel.first")
last =3D self.text.index("sel.last")
return first, last
except TclError:
return None, None
# Return the text widget's current view of what a tab stop means
# (equivalent width in spaces).
def get_tabwidth(self):
current =3D self.text['tabs'] or TK_TABWIDTH_DEFAULT
return int(current)
# Set the text widget's current view of what a tab stop means.
def set_tabwidth(self, newtabwidth):
text =3D self.text
if self.get_tabwidth() !=3D newtabwidth:
pixels =3D text.tk.call("font", "measure", text["font"],
"-displayof", text.master,
"n" * newtabwith)
text.configure(tabs=3Dpixels)
def prepstr(s):
# Helper to extract the underscore from a string, e.g.
# prepstr("Co_py") returns (2, "Copy").
i =3D string.find(s, '_')
if i >=3D 0:
s =3D s[:i] + s[i+1:]
return i, s
keynames =3D {
'bracketleft': '[',
'bracketright': ']',
'slash': '/',
}
def get_accelerator(keydefs, event):
keylist =3D keydefs.get(event)
if not keylist:
return ""
s =3D keylist[0]
s =3D re.sub(r"-[a-z]\b", lambda m: string.upper(m.group()), s)
s =3D re.sub(r"\b\w+\b", lambda m: keynames.get(m.group(), =
m.group()), s)
s =3D re.sub("Key-", "", s)
s =3D re.sub("Control-", "Ctrl-", s)
s =3D re.sub("-", "+", s)
s =3D re.sub("><", " ", s)
s =3D re.sub("<", "", s)
s =3D re.sub(">", "", s)
return s
def fixwordbreaks(root):
# Make sure that Tk's double-click and next/previous word
# operations use our definition of a word (i.e. an identifier)
tk =3D root.tk
tk.call('tcl_wordBreakAfter', 'a b', 0) # make sure word.tcl is =
loaded
tk.call('set', 'tcl_wordchars', '[a-zA-Z0-9_]')
tk.call('set', 'tcl_nonwordchars', '[^a-zA-Z0-9_]')
def test():
root =3D Tk()
fixwordbreaks(root)
root.withdraw()
if sys.argv[1:]:
filename =3D sys.argv[1]
else:
filename =3D None
edit =3D EditorWindow(root=3Droot, filename=3Dfilename)
edit.set_close_hook(root.quit)
root.mainloop()
root.destroy()
if __name__ =3D=3D '__main__':
test()
------=_NextPart_000_0000_01BF924B.18F7D1C0
Content-Type: text/plain;
name="EventManager.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="EventManager.py"
class EventManager:
def __init__ (self):
print "initialized"
self.evtmgr=3D{}
def typeSort (self, one, two):
return cmp(one[1], two[1])
##
## This functions registers all callbacks that have to be called =
before the default callback
## is initiated
##
def registerAfterCallback (self, itemName, defaultCallback, =
type=3D3):
if not self.evtmgr.has_key(itemName):
raise "No DefaultCallback found for "+itemName
self.evtmgr[itemName].append((defaultCallback,type,None,None))
self.evtmgr[itemName].sort(self.typeSort) =09
##
## This functions registers all callbacks that have to be called =
after the default callback
## is initiated
##
def registerBeforeCallback (self, itemName, defaultCallback, =
type=3D1):
if not self.evtmgr.has_key(itemName):
raise "No DefaultCallback found for "+itemName
self.evtmgr[itemName].append((defaultCallback,type,None,None))
self.evtmgr[itemName].sort(self.typeSort) =09
##
## This functions registers the default callback. This function =
replaces the xxx.bind calls
## for all interceptable events.
##
def registerDefaultCallback (self, widget, itemName, =
defaultCallback, type=3D2):
##
## If the Event is registered the first time a real Tcl/Tk =
callback must be added
## this callback points to the driveEvent Function where the =
registered Callback will
## be initiated if the event is triggered ?!
##
if not self.evtmgr.has_key(itemName):
evtbind=3Dwidget.bind(itemName, lambda e, =
cb=3Dself.driveEvent, itemName=3DitemName: cb(e, itemName))
self.evtmgr[itemName]=3D[]
else:
raise "DefaultCallback already registered for "+itemName
=
self.evtmgr[itemName].append((defaultCallback,type,widget,evtbind))
self.evtmgr[itemName].sort(self.typeSort) =09
##
## This functions removes the defautl callbacks and all attached =
callbacks.
##
def unregisterDefaultCallback (self, itemName):
self.evtmgr[itemName][0][2].unbind (itemName, =
self.evtmgr[itemName][0][3])
self.evtmgr[itemName]=3DNone
##
## Process an event by calling all callbakcs registered
##
def driveEvent (self, event, name):
results=3D{}
print len(self.evtmgr[name])
for calls,type,widget,evtbind in self.evtmgr[name]:
print "####"
results=3Dcalls (results)
##To add the standard functionality :
##
## def openfile (itemName, params):
## if !params.has_key("defaultdir"):
## ... use standard directory to open file dialog ...
## else:
## ... use params["defaultdir"] ...
##
## ... after selectting a file ...
## params["filename"]=3Dthe_filename
## return (params)
##
## menuRegisterCallback ("File/Open...", openfile, 2)
##
##To intercept:
##
## def maintainRecentlist (itemName, params):
## addFileToRecentList (itemName)
## return (params) ## do nothing with the params
##
## menuRegisterCallback ("File/Open...", maintainRecentList, 3)
------=_NextPart_000_0000_01BF924B.18F7D1C0
Content-Type: text/plain;
name="extend.py"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="extend.py"
# IDLE extensions to be loaded by default (see extend.txt).
# Edit this file to configure your set of IDLE extensions.
standard = [
"SearchBinding",
"AutoIndent",
"AutoExpand",
"FormatParagraph",
"ZoomHeight",
"ScriptBinding",
"CallTips",
"RecentList",
]
------=_NextPart_000_0000_01BF924B.18F7D1C0--
From goddard@cgl.ucsf.EDU Thu Mar 23 22:40:46 2000
From: goddard@cgl.ucsf.EDU (Thomas Goddard)
Date: Thu, 23 Mar 2000 14:40:46 -0800 (PST)
Subject: [Idle-dev] Embedding IDLE
Message-ID: <200003232240.OAA138704@socrates.cgl.ucsf.edu>
Here are some suggestions to facilitate embedding IDLE as part of
another Tkinter application.
I work on a molecular visualization program that is user extendable in
Python. I want to be able to start IDLE from this program. IDLE will
run in the same Python interpretter as the molecular visualization program.
To start an IDLE shell window within the molecular visualization program
IDLE should not do some of the steps it does when started standalone:
1) Don't do command-line argument parsing
2) Don't start the Tkinter event loop
3) Don't call Tkinter quit() when the last IDLE window is closed
4) Don't reset Tkinter _default_root to None
To achieve 1) and 2) the IDLE 0.5 shell window initialization code in
PyShell.py main() needs to be separated out from the command-line argument
parsing and event loop start-up. This just involves packaging about 10
lines of code in a separate routine.
When the last IDLE window closes, the FileList close_edit() method in
FileList.py calls Tkinter quit() exitting the event loop. This should
only be done if the PyShell.py main() routine called Tkinter mainloop().
In the PyShell class the begin() routine sets Tkinter._default_root = None.
I guess this is so that code run in IDLE sees a clean Tkinter. This should
not be done if IDLE is running within another Tkinter application as it can
break the graphical interface of that application. The _default_root = None
code could be moved to PyShell.py main(). This changes the behaviour of
IDLE, since Tkinter _default_root will then only be set once when starting
IDLE standalone, instead of each time a PyShell is created.
The molecular visualization code wants to redisplay the IDLE shell window
if the user asks for it a second time. It would be helpful to have a
method of the IDLE EditorWindow class to determine if the window has been
closed, so I don't try to raise a destroyed window.
Tom Goddard
Computer Graphics Lab
UC San Francisco
From guido@python.org Fri Mar 24 22:46:16 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 24 Mar 2000 17:46:16 -0500
Subject: [Idle-dev] Embedding IDLE
In-Reply-To: Your message of "Thu, 23 Mar 2000 14:40:46 PST."
<200003232240.OAA138704@socrates.cgl.ucsf.edu>
References: <200003232240.OAA138704@socrates.cgl.ucsf.edu>
Message-ID: <200003242246.RAA16075@eric.cnri.reston.va.us>
> Here are some suggestions to facilitate embedding IDLE as part of
> another Tkinter application.
>
> I work on a molecular visualization program that is user extendable in
> Python. I want to be able to start IDLE from this program. IDLE will
> run in the same Python interpretter as the molecular visualization program.
>
> To start an IDLE shell window within the molecular visualization program
> IDLE should not do some of the steps it does when started standalone:
>
> 1) Don't do command-line argument parsing
> 2) Don't start the Tkinter event loop
> 3) Don't call Tkinter quit() when the last IDLE window is closed
> 4) Don't reset Tkinter _default_root to None
>
> To achieve 1) and 2) the IDLE 0.5 shell window initialization code in
> PyShell.py main() needs to be separated out from the command-line argument
> parsing and event loop start-up. This just involves packaging about 10
> lines of code in a separate routine.
>
> When the last IDLE window closes, the FileList close_edit() method in
> FileList.py calls Tkinter quit() exitting the event loop. This should
> only be done if the PyShell.py main() routine called Tkinter mainloop().
>
> In the PyShell class the begin() routine sets Tkinter._default_root = None.
> I guess this is so that code run in IDLE sees a clean Tkinter. This should
> not be done if IDLE is running within another Tkinter application as it can
> break the graphical interface of that application. The _default_root = None
> code could be moved to PyShell.py main(). This changes the behaviour of
> IDLE, since Tkinter _default_root will then only be set once when starting
> IDLE standalone, instead of each time a PyShell is created.
All good suggestions -- we'll work on these!
> The molecular visualization code wants to redisplay the IDLE shell window
> if the user asks for it a second time. It would be helpful to have a
> method of the IDLE EditorWindow class to determine if the window has been
> closed, so I don't try to raise a destroyed window.
I think you can already do this, using the open_shell() method of the
PyShellFileList class defined in PyShell.py? Or do I misunderstand
what you want?
--Guido van Rossum (home page: http://www.python.org/~guido/)
From boyle5@llnl.gov Thu Mar 30 17:34:00 2000
From: boyle5@llnl.gov (Jim Boyle)
Date: Thu, 30 Mar 2000 09:34:00 -0800
Subject: [Idle-dev] (no subject)
Message-ID:
I've been using Dave Scherer's version of idle (XIDLE-1000-03-13.zip).
I strongly support these changes, I now use idle regularly, whereas
before I only used it out of idle curiosity.
It fits very well with the way I work and develop code.
My only glitch is the saving of named buffers automatically before
running. This is convenient but I have been burned by making changes
and then deciding to go back only to find that my original is gone.
Perhaps, if an explicit save is not done there could be a backup made
a la emacs.
Jim
From guido@python.org Thu Mar 30 20:06:46 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 Mar 2000 15:06:46 -0500
Subject: [Idle-dev] (no subject)
In-Reply-To: Your message of "Thu, 30 Mar 2000 09:34:00 PST."
References:
Message-ID: <200003302006.PAA21996@eric.cnri.reston.va.us>
> I've been using Dave Scherer's version of idle (XIDLE-1000-03-13.zip).
> I strongly support these changes, I now use idle regularly, whereas
> before I only used it out of idle curiosity.
> It fits very well with the way I work and develop code.
Yes, we're planning to implement something like this before Python 1.6
final comes out. We have something slightly more ambitious in mind,
so please be patient.
> My only glitch is the saving of named buffers automatically before
> running. This is convenient but I have been burned by making changes
> and then deciding to go back only to find that my original is gone.
> Perhaps, if an explicit save is not done there could be a backup made
> a la emacs.
Making backups is a good policy anyway, this needs to be added.
But it should at least ask before saving. I guess if you don't save
it can't run, because the other process can't see the unsaved source.
Also note that you can use undo to go back before the last save!
--Guido van Rossum (home page: http://www.python.org/~guido/)
From glyph@twistedmatrix.com Thu Mar 30 20:24:25 2000
From: glyph@twistedmatrix.com (Glyph Lefkowitz)
Date: Thu, 30 Mar 2000 15:24:25 -0500 (EST)
Subject: [Idle-dev] IDLE, Tk, and WindowMaker
Message-ID:
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---1463792895-1920459476-954444532=:2201
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID:
(note: lots of this is Tk specific, so if I'm addressing this issue in the
wrong forum feel free to redirect me)
Hi everyone!
IDLE is a really nifty IDE. I hadn't really considered trying it, because
Tk is ugly, buggy and functions incorrectly with many windowmanagers
(Enlightenment, fvwm, IceWM, and Sawmill come to mind). The particularly
annoying bug that these WMs exhibit with Tk is that sometimes when an
event is processed (particularly frequently when closing a window or
tearing off a menu) the program will hang for 10-30 seconds before drawing
anything to the screen.
In order to fix the 'ugly' problem, I installed Tkstep. IDLE, and all
Python/Tk programs, work wonderfully with this little hack. Continuing in
the NeXTSTEP theme, to work around Tk's allergy to the ICCCM, (and for
various other reasons, which I'll get to in a moment) WindowMaker, which
seems to allow it to at least process events correctly. After munging a
few Xdefaults, I had a very nice looking setup which integrated nicely
with the rest of my desktop, and didn't hang when I tried to use menus.
I heard that IDLE 0.5 was significantly niftier than the debian packaged
version, 0.4, and indeed it is! I played with it and was very impressed
with the popup argument-listing ;-). Is something like VB's '.' completion
in the works? (I always loved that feature, but couldn't stomach actually
writing VB)
However, there is a final problem. Something which I gather is only a
problem for WindowMaker users, but seems odd in general. The specific
problem is that IDLE does not produce a usable app-icon. This is a pretty
big deal for me, because I use a lot of apps, frequently all at the same
time; I use WMaker's facility for hiding and showing these rather
frequently. It is MUCH more convenient than "workspaces", since I don't
have to manually associate windows with a group; X does it for me. I also
prefer to use them to launch applications. The first part I have mostly
fixed (see the attached tiny patch against 0.5 -- I also fixed a minor
typo ^_^) but the second is that Tk seems to flaunt established
conventions for the WM_CLASS hint.
glyph@helix:~% xprop | grep CLASS
Clicking on their various windows;
IDLE says: WM_CLASS(STRING) = "135690688", "Toplevel"
Gnome Terminal says: WM_CLASS(STRING) = "GnomeTerminal", "GnomeTerminal.2"
XEmacs says: WM_CLASS(STRING) = "emacs", "Emacs"
Netscape says: WM_CLASS(STRING) = "Navigator", "Netscape"
To quote the venerable Sesame Street, "One of these things is not like the
others. One of these things is not the same." :-)
Attempting to change this particular thing was no good, either. I noticed
that WM_CLASS is sent according to the className of the widget and
attempted to change the WM_CLASS/name of EditorWindow by changing its
_name... then I noticed and there's this snippet of code in
Tkinter.BaseWidget._setup:
if self.master.children.has_key(self._name):
self.master.children[self._name].destroy()
self.master.children[self._name] = self
which means if 2 Tkinter.Toplevel windows in the same [group? root
somethingorother?] have the same WM_CLASS (as other apps indicate they're
supposed to) one of the others will disappear. I watched a few
EditorWindows just vanish inexplicably before figuring this out.
The most important thing, though, is that the "group leader" window
('root', in this case) doesn't seem to have any WM_CLASS at *all*. (I
can't prove this, because if I don't withdraw() it, it seems to have the
class of tk#2.Tk...?) The result of this is that the appicon behaves
erratically (I can provide more specifics if you're interested) and that
when I right-click on it, it doesn't know what application that icon is
associated with. WMaker uses the second half of the WM_CLASS
specification of the group leader window by default, I believe, giving
XEmacs an application name of 'Emacs', netscape of 'Netscape', etcetera.
I can't figure out a way to change this.
Can anyone with a high degree of Tk Zen perhaps explain this to me? I
wish I could have finished the patch before submitting it here, but I am
definitely way out of my depth.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
http://www.twistedmatrix.com/~glyph/
---1463792895-1920459476-954444532=:2201
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="idle-appicon.patch"
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description: idle-appicon.patch
Content-Disposition: ATTACHMENT; FILENAME="idle-appicon.patch"
ZGlmZiAtdSBpZGxlLW9yaWcvRWRpdG9yV2luZG93LnB5IGlkbGUtMC41L0Vk
aXRvcldpbmRvdy5weQ0KLS0tIGlkbGUtb3JpZy9FZGl0b3JXaW5kb3cucHkJ
VHVlIEZlYiAxNSAxMzowNToxNSAyMDAwDQorKysgaWRsZS0wLjUvRWRpdG9y
V2luZG93LnB5CVdlZCBNYXIgMjkgMjA6MzQ6MjYgMjAwMA0KQEAgLTEwMSw2
ICsxMDEsNyBAQA0KICAgICAgICAgICAgIHNlbGYudmFycyA9IGZsaXN0LnZh
cnMNCiAgICAgICAgIHNlbGYubWVudWJhciA9IE1lbnUocm9vdCkNCiAgICAg
ICAgIHNlbGYudG9wID0gdG9wID0gc2VsZi5Ub3BsZXZlbChyb290LCBtZW51
PXNlbGYubWVudWJhcikNCisgICAgICAgIHNlbGYudG9wLmdyb3VwKHJvb3Qp
DQogICAgICAgICBzZWxmLnZiYXIgPSB2YmFyID0gU2Nyb2xsYmFyKHRvcCwg
bmFtZT0ndmJhcicpDQogICAgICAgICBzZWxmLnRleHRfZnJhbWUgPSB0ZXh0
X2ZyYW1lID0gRnJhbWUodG9wKQ0KICAgICAgICAgc2VsZi50ZXh0ID0gdGV4
dCA9IFRleHQodGV4dF9mcmFtZSwgbmFtZT0ndGV4dCcsIHBhZHg9NSwNCkBA
IC02NjQsNyArNjY1LDcgQEANCiAgICAgICAgIGlmIHNlbGYuZ2V0X3RhYndp
ZHRoKCkgIT0gbmV3dGFid2lkdGg6DQogICAgICAgICAgICAgcGl4ZWxzID0g
dGV4dC50ay5jYWxsKCJmb250IiwgIm1lYXN1cmUiLCB0ZXh0WyJmb250Il0s
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICItZGlzcGxh
eW9mIiwgdGV4dC5tYXN0ZXIsDQotICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICJuIiAqIG5ld3RhYndpdGgpDQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICJuIiAqIG5ld3RhYndpZHRoKQ0KICAgICAg
ICAgICAgIHRleHQuY29uZmlndXJlKHRhYnM9cGl4ZWxzKQ0KIA0KIGRlZiBw
cmVwc3RyKHMpOg0KQ29tbW9uIHN1YmRpcmVjdG9yaWVzOiBpZGxlLW9yaWcv
SWNvbnMgYW5kIGlkbGUtMC41L0ljb25zDQpkaWZmIC11IGlkbGUtb3JpZy9Q
eVNoZWxsLnB5IGlkbGUtMC41L1B5U2hlbGwucHkNCi0tLSBpZGxlLW9yaWcv
UHlTaGVsbC5weQlGcmkgSnVuIDI1IDEyOjI2OjM0IDE5OTkNCisrKyBpZGxl
LTAuNS9QeVNoZWxsLnB5CVdlZCBNYXIgMjkgMjA6Mjc6MjEgMjAwMA0KQEAg
LTcxMSw2ICs3MTEsOCBAQA0KICAgICByb290ID0gVGsoKQ0KICAgICBmaXh3
b3JkYnJlYWtzKHJvb3QpDQogICAgIHJvb3Qud2l0aGRyYXcoKQ0KKyAgICBy
b290Lmdyb3VwKHJvb3QpDQorICAgIHJvb3QuY29tbWFuZCgnaWRsZScpDQog
ICAgIGZsaXN0ID0gUHlTaGVsbEZpbGVMaXN0KHJvb3QpDQogDQogICAgIGlm
IGVkaXQ6DQo=
---1463792895-1920459476-954444532=:2201--
From gritsch@iue.tuwien.ac.at Fri Mar 31 11:50:06 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Fri, 31 Mar 2000 13:50:06 +0200
Subject: [Idle-dev] Python 1.6 stackless?
References: <200003302006.PAA21996@eric.cnri.reston.va.us>
Message-ID: <38E490EE.82D7D392@iue.tuwien.ac.at>
Guido van Rossum wrote:
> Yes, we're planning to implement something like this before Python 1.6
> final comes out.
By the way, are you planning to use some advanced version of 'Stackless
Python' in the 1.6 Release, or are you sticking with the 'normal' Python
implemention?
--
Markus
From guido@python.org Fri Mar 31 12:16:29 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 31 Mar 2000 07:16:29 -0500
Subject: [Idle-dev] Python 1.6 stackless?
In-Reply-To: Your message of "Fri, 31 Mar 2000 13:50:06 +0200."
<38E490EE.82D7D392@iue.tuwien.ac.at>
References: <200003302006.PAA21996@eric.cnri.reston.va.us>
<38E490EE.82D7D392@iue.tuwien.ac.at>
Message-ID: <200003311216.HAA29049@eric.cnri.reston.va.us>
> > Yes, we're planning to implement something like this before Python 1.6
> > final comes out.
>
> By the way, are you planning to use some advanced version of 'Stackless
> Python' in the 1.6 Release, or are you sticking with the 'normal' Python
> implemention?
Stackless is still heresy. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
From gritsch@iue.tuwien.ac.at Fri Mar 31 12:18:52 2000
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Fri, 31 Mar 2000 14:18:52 +0200
Subject: [Idle-dev] Python 1.6 stackless?
References: <200003302006.PAA21996@eric.cnri.reston.va.us>
<38E490EE.82D7D392@iue.tuwien.ac.at> <200003311216.HAA29049@eric.cnri.reston.va.us>
Message-ID: <38E497AC.C4E0087D@iue.tuwien.ac.at>
Guido van Rossum wrote:
> > > Yes, we're planning to implement something like this before Python 1.6
> > > final comes out.
> >
> > By the way, are you planning to use some advanced version of 'Stackless
> > Python' in the 1.6 Release, or are you sticking with the 'normal' Python
> > implemention?
>
> Stackless is still heresy. :-)
Can you be a little bit more specific ?-)
--
Markus
From guido@python.org Fri Mar 31 12:40:29 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 31 Mar 2000 07:40:29 -0500
Subject: [Idle-dev] Python 1.6 stackless?
In-Reply-To: Your message of "Fri, 31 Mar 2000 14:18:52 +0200."
<38E497AC.C4E0087D@iue.tuwien.ac.at>
References: <200003302006.PAA21996@eric.cnri.reston.va.us> <38E490EE.82D7D392@iue.tuwien.ac.at> <200003311216.HAA29049@eric.cnri.reston.va.us>
<38E497AC.C4E0087D@iue.tuwien.ac.at>
Message-ID: <200003311240.HAA29080@eric.cnri.reston.va.us>
> > > By the way, are you planning to use some advanced version of 'Stackless
> > > Python' in the 1.6 Release, or are you sticking with the 'normal' Python
> > > implemention?
> >
> > Stackless is still heresy. :-)
>
> Can you be a little bit more specific ?-)
I am sticking with the 'normal' Python implementation. :-)
BTW what does this have to do with IDLE?
--Guido van Rossum (home page: http://www.python.org/~guido/)
From tismer@tismer.com Fri Mar 31 12:59:38 2000
From: tismer@tismer.com (Christian Tismer)
Date: Fri, 31 Mar 2000 14:59:38 +0200
Subject: [Idle-dev] Python 1.6 stackless?
References: <200003302006.PAA21996@eric.cnri.reston.va.us> <38E490EE.82D7D392@iue.tuwien.ac.at> <200003311216.HAA29049@eric.cnri.reston.va.us>
<38E497AC.C4E0087D@iue.tuwien.ac.at> <200003311240.HAA29080@eric.cnri.reston.va.us>
Message-ID: <38E4A13A.13D19030@tismer.com>
Guido van Rossum wrote:
>
> > > > By the way, are you planning to use some advanced version of 'Stackless
> > > > Python' in the 1.6 Release, or are you sticking with the 'normal' Python
> > > > implemention?
> > >
> > > Stackless is still heresy. :-)
> >
> > Can you be a little bit more specific ?-)
>
> I am sticking with the 'normal' Python implementation. :-)
>
> BTW what does this have to do with IDLE?
IDLE could use a completely different model for its event
handling. But the first co-anyting driven GUI will most
probably be mark Wilson's Build (unless /F is faster).
1024 thanks for givin Stackless a new name!
heretic-ly y'rs - chris
--
Christian Tismer :^)
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home
From barmeier@BARMEIER.COM Fri Mar 31 18:19:53 2000
From: barmeier@BARMEIER.COM (Matthias Barmeier)
Date: Fri, 31 Mar 2000 20:19:53 +0200
Subject: [Idle-dev] Extends an events
Message-ID:
Hi,
my experimental code for a new event model I sent to this mailing list
seems to be ignored.
May be anyone could tell why ?
Was the code so bad that no one knows what to do with it or
had I violated some unknown rules of sending source code ?
Please tell me.
Ciao
Matthias
/*
Dipl.-Inform. Matthias Barmeier Tel: +49 (0)30 79 70 72 87
Büro für Softwareentwicklung Fax +49 (0)30 79 70 72 88
Grunewaldstr. 18 Email: barmeier@barmeier.com
12165 Berlin WWW:
*/
From guido@python.org Fri Mar 31 18:33:02 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 31 Mar 2000 13:33:02 -0500
Subject: [Idle-dev] Extends an events
In-Reply-To: Your message of "Fri, 31 Mar 2000 20:19:53 +0200."
References:
Message-ID: <200003311833.NAA24059@eric.cnri.reston.va.us>
> my experimental code for a new event model I sent to this mailing list
> seems to be ignored.
>
> May be anyone could tell why ?
>
> Was the code so bad that no one knows what to do with it or
> had I violated some unknown rules of sending source code ?
>
> Please tell me.
I'm going out on a lark and assume that you had expected me to look at
it. Unfortunately I haven't had the time yet -- I was on a 10-day
trip, and now I'm trying to get Python 1.6a1 pushed out of the door
within a few hours. I'll try to have a look at it next week, but the
post-alpha-release frenzy might get in the way at first.
If you're looking for a rule you violated, I would say that your post
didn't start with a clear description of: (1) what is the problem; (2)
why is that problem important to you; (3) what is your approach to
solving the problem. If you could post that separately, it would be
much appreciated.
--Guido van Rossum (home page: http://www.python.org/~guido/)