Author terry.reedy
Recipients asvetlov, cben, cheryl.sabella, gpolo, kbk, mark, markroseman, terry.reedy
Date 2018-02-06.07:25:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Currently, Shell start and restart act differently.  Start can execute one of -s file, -c command, or neither (and there are other command line options).  Restart prints a RESTART separator banner and optionally runs an edit buffer, but ignores all or most command-line options.

I would like to try to solve this and related issues by simplifying pyshell so that there is a uniform user process startup, rather than initial start and later restart.  Shell would always print a START header banner, adjusted according to which, if any, pre-defined code it was going to run, run the code, and then print a prompt for interactive input.

My hesitation about making -s or -c repeat, expressed on another issue, is that someone might want stop repeating with exiting.  I think an adequate solution would be a new section of the Shell menu with radio buttons such as () No startup, () Start file, and () Start command, with inapplicable choices grayed out.

The above should be a separate new issue and a dependency of this one.

This issue has 2 parts.

1. Make it possible to run Shell startup code when IDLE is not started from the command line, which it usually is not, and without adding a separate startup script and icon.  The two subproposals are storing in IDLE's user config either a filename (which file could also be used without IDLE) or a code block.  I am willing to do both. 

2. Make it possible to run the new Shell startup code each time Shell starts without running editor code.  I don't want to do 1. without 2., and I don't want to make re-running possibly only for new sources.  I propose that we first fix re-running for existing sources, as described above, so that when 1. is done after, 2. easily follows.

About the patch: You picked a non-trivial issue ;-), and review will not be quick.  Could you list the 'other issues'?  Even if they are handled later with separate PRs (if not rejected) I want to have them in mind before doing this.  For instance, they may affect my idea of how we should split the General tab.

I am not sure whether I have ever tested that -s, for instance, works correctly.  Certainly not recently.  User code must be exec'ed within the run process by code and not run in main's global context by python.  This is why I am unsure about using -c, as that should do the latter before run code takes over.

Editor template code is different issue.  I think it needs separate discussion, with consideration of how other editors work.  AFAIK, there is no existing issue, so a new one is needed.

My own use case, is for a separate project where most files, but not all, start with a template.  Currently with IDLE, I open the template and immediately save with the new name.  If I could instead start with a blank and insert the template, I could not accidentally overwrite.  With multiple projects, I would probably want multiple templates.  The File menu could have a entry such as 'New, with template'.

I have expected to split the General tab. I was thinking there should be a new 'Editor' tab, which would seem to be the place for editor template information.   I think both template file(s) and a config template block  should be options.

For code entry, whether startup code or template, the patch uses a Text widget with scrollbar added.  I believe tkinter already has such.  However, I agree with Cherniavsky that an IDLE editor would be even better.  However, we really need a small editor frame, with no menu, rather than a separate window.  The OK and Apply buttons would  'save' the contents.

I have already intended to factor a subclassable editor frame out of EditorWindow.  (I have also thought of using a subclass of such as the code entry area for Shell.)  Startup and template code would be two other uses.
Date User Action Args
2018-02-06 07:25:26terry.reedysetrecipients: + terry.reedy, kbk, cben, mark, gpolo, asvetlov, markroseman, cheryl.sabella
2018-02-06 07:25:26terry.reedysetmessageid: <>
2018-02-06 07:25:26terry.reedylinkissue5594 messages
2018-02-06 07:25:26terry.reedycreate