Terry J. Reedy <tjre...@udel.edu> added the comment: 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 run.py 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. ---------- title: IDLE startup configuration -> IDLE: execute stored startup code on each Shell start. versions: +Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue5594> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
