[Idle-dev] Startup Shell Functionality
David Scherer
dscherer@vysics.com
Mon, 16 Jul 2001 20:11:15 -0400
> OK, output into an interactive "shell" window which resets
> its environment with each run, but which keeps the output of
> previous run(s) around with delimiting separators.
>
> I'd suggest that to avoid massive confusion by students, that
> in that part of the buffer associated with previous runs the
> left margin be padded with a character to let people know it
> belongs to a previous environment.
Sounds like a good use for a different color, which would set things off
even better and wouldn't interfere with cut and paste. However, I
should also note that (correct me if I'm wrong, Bruce!) we haven't seen
that much confusion of this kind given the scrolling behavior (see next
paragraph).
> Something like, save the previous output, pad those parts not
> yet padded, append a fairly strident separator, start the new
> shell, toss in this stuff, then add the new output?
I made OutputWindow scroll so that the top line is the first line of the
new output. This mostly combines the advantages of clearing the window
with the advantages of keeping the old stuff.
> Are we keeping all the old sessions, or just the previous one?
The existing implementation keeps all, and it hasn't been a problem in
practice as far as I know.
> Hmm, opening a new window will slow things down, I notice
> that idlefork reuses the output window and it's much faster
> the second and subsequent runs. I wonder if it's hard to
> reuse the "shell" window? And if we have to start a new one,
> we should kill the previous one to avoid clutter and confusion.
Reuse the window for different runs of the same program. For runs of
different programs this is debatable, and some kind of fancy tabbed
(multi-buffer) window would probably be ideal. I don't suggest
confounding that feature with this one, though!
> Is the "hit return to copy text to the end" function supposed
> to work, i.e. does this buffer do everything a Python IDLE shell does?
Well, why not? :)
This is where Guido's remote execution patch probably comes in -
presumably he found a good way to use all of that PyShell functionality
over RPC.
Dave