[Idle-dev] Re: idlefork - update, current tasks

[Stephen M. Gava]

Kurt B. Kaiser wrote:
[... on the new rpc/spe]
> It seems to me that we two are likely to break Idlefork pretty badly
> at times at first, which would slow down the work that you and Raymond
> are doing.  In addition, I would expect the two versions to start to
> diverge, especially in the output window (see below).
> 
> Therefore, might I also suggest that we fork the current version just
> before Chui's merge and that you and Raymond work 

I tagged the files in idle/ and below with TAG_pre_teyc_gvr_rpc_patch
just before Chui's commit of this.

> This has the advantage that a relatively stable version would be
> available in the interim for comparison and also for end user
> downloads.

> The argument parsing in PyShell.main.main() appears to be OK and met
> GvR's requests last July.  The args passed to PyShell.main.remote()
> would seem to be a subset, but it's unfinished.  The call in
> PyShell.main.__init__ also has some redundancy, the usageError stuff
> probably could be diked out.  The help message needs to be made
> consistent with the usage message.
> 
> The code for the new design will probably have different start up
> functionality, though.

> > The idea is that results for run programs be output to a real python
> > shell window to allow interactive inspection of results etc.. The
> > results would have to be delimited in some way and different outputs for
> > code run from different editor windows handled. Guido says he likes the
> > way this is done in TeachScheme, although I must admit I haven't had the
> > chance to look at that.
>
> I have used DrScheme.  They have a good system in which once the code
> is run in the remote window you can use that window as a shell to
> examine the environment and define and run procedures, like you would
> in the Python shell.  It doesn't disconnect like the DS code does.
> However, if you change the text in the Edit window, the remote window
> is marked as out of synch and you have to re-run the code.  Doing that
> restarts the remote REPL with a fresh environment.  One nice thing
> with DrScheme is you can cut/paste back and forth between the two
> windows.  Last I heard, a new version was in alpha.
> 
> http://www.cs.rice.edu/CS/PLT/packages/drscheme/tour/slide10.htm 
> 
> I think that is close to what Guido wanted:
> 
> http://mail.python.org/pipermail/idle-dev/2001-July/000504.html
> http://mail.python.org/pipermail/idle-dev/2001-July/000506.html
> 
> and, as you suggest, with that approach we don't need a separate
> shell.  Perhaps if you F5 an empty edit window it brings up a shell?

We absolutely need to retain the functionality of having a separate, and
directly accessible from the menus 'shell only' window that can be
opened as desired for tooling around in.  

> In our case, do I understand that the presence of the shell
> at startup is now a user config?

That only relates to the default choice of having a shell or an editor
open up first, which is overridden by the command line spec of files to
edit or specific switches.

> Would you like me to update the Idle vendor branch so a formal merge
> could be done, as before, but using the diff between now and last summer?

Do you mean a merge from python idle? This should be unnecessary since
I've tracked every change to python idle since then. In fact I think
there have been fixes and behavioural improvements in idlefork that
aren't in idle.

-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only
crunchy "