Startup Sequence

MrEd starts up with the following sequence of actions:

• Collection Search Path: (See also library collections.) The collection search path is initialized from the PLTCOLLECTS environment variable. If PLTCOLLECTS is set, it is expected to be a colon-separated list of pathnames; these pathnames are used (in order) as the default collection search path. If PLTCOLLECTS contains an empty path, it is replaced with the default collections path, which is decribed below. If PLTCOLLECTS is not set (it is never set under MacOS), the default collection search path will contain only the default collections path.

  The default collections path uses the PLTHOME envionment variable, or finds a collects directory relative to the MrEd executable's directory, or (as a last resort) uses a platform-specific default. More precisely, the default collections path is the first of the following paths that exists:

  • (build-path (getenv "PLTHOME") "collects") if the PLTHOME environment variable is set
  • (find-executable-path program "collects") where program is the MrEd executable name (as identified by the operating system when MrEd was started); whenever program is a complete path (always under MacOS and Windows), find-executable-path returns a pathname specifying the ``collects'' directory in the same directory as the MrEd executable.
  • "/usr/local/lib/plt/collects" (X Windows only)
  • "C:\plt\collects" (Windows only)

  The algorithm for setting the collection search path is expressed by the following MzScheme expression, where PROGRAM is bound to the name of the MrEd executable:

  (current-library-collection-paths
   (path-list-string->path-list
    (or (getenv "PLTCOLLECTS") "")
    (or (ormap
         (lambda (p) (and p (directory-exists? p) (list p)))
         (list
          (let ((v (getenv "PLTHOME")))
            (and v (build-path v "collects")))
          (find-executable-path PROGRAM "collects")
          (case (system-type)
            [(unix) "/usr/local/lib/plt/collects"]
            [(windows) "C:\\plt\\collects"]
            [(macos) #f])))
        null)))

• The --pre Flag: If the first command-line flag is --pre, then the next argument is read and evaluated as a Scheme expression. This expression is evaluated in the main thread and in a namespace that contains only MzScheme's built-in syntax and procedures.

  The --pre thread's parameterization is the initial parameterization, from which all other parameterizations are derived. Thus, changing a parameter value in this parameterization effectively overrides the built-in default value for MrEd.

  See for information about command-line arguments under MacOS.

• X Windows Flags: Under X Windows, the following standard X Windows flags are recognized (but not necessarily implemented): -display (1 argument), -geometry (1 argument), -bg (1 argument), -background (1 argument), -fg (1 argument), -foreground (1 argument), -fn (1 argument), -font (1 argument), -iconic (0 arguments), -name (1 argument), -rv (0 argument), -reverse (0 arguments), -rv (0 arguments), -selectionTimeout (1 argument), -synchronous (0 arguments), -title (1 argument), -xnllanguage (1 argument), and -xrm (1 argument).

  All X Windows flags must follow --pre's argument if --pre is used, and X Windows flags and arguments must precede all other flags and arguments.

• Font Settings: MrEd reads the font settings from the file:
  • .mred.resources in the users's home directory under X Windows;
  • mred.ini, under Windows; if the HOMEDRIVE and HOMEPATH environment variables are set, mred.ini is read from the %HOMEDRIVE%\%HOMEPATH% directory, otherwise mred.ini is read from MrEd.exe's directory; or,
  • mred.fonts in the system preferences folder under MacOS.
• Initial Eventspace: MrEd creates an initial eventspace with a parameterization obtained from the parameterizaton branch handler in the initial parameterization. (The handler thread for this eventspace is not MrEd's main thread; the main thread is inaccessible unless it is made accessible by the --pre expression.)
• System: MrEd loads its operating system by reference-librarying (see library collections for more info) the system.ss library from the system collection. The system must define a mred:initialize function to be called later.

  By default, the system collection name is system. A different collection for the system can be specified with the -s flag followed by a collection name argument. The -s flag must follow the --pre and X Windows flags and arguments if they are present, and it must precede all other flags and arguments.

  The system is loaded by the initial eventspace's main thread into a namespace that contains all of the built-in MzScheme syntax and procedures, the wx^ signature, the wx@ signed unit (see Core Toolbox), and the global variables defined by using invoke-open-unit/sig on the wx@ unit with the prefix wx:. The same namespace was used for evaluating the --pre expression (before the wx: definitions were added); if the --pre expression modifies the namespace, the modifications will be intact when the system is loaded.

• Initialization: After the system is loaded, mred:initialize is called with the remaining command line arguments as strings. (The ``remaining'' arguments are all command-line flags and arguments after the --pre, X Windows, and -s flags and arguments.) The mred:initialize procedure is called in the main thread of the initial eventspace and the result is ignored.

After mred:initialize returns, MrEd runs until the default exit handler is invoked.

The system collection's mred:initialize performs the following sequence of actions:

• Application Specifying Flags: These command line flags are used to choose an application. The recognized command-line flags are:

  -A The next argument is set as the collection for the application. See also the info.ss section.

  -a The next three arguments are used to specify a collection, and two files in that collection: a file containing a unit and a file containing a signature. They are used as the startup application. This is an alternative to the info.ss specification of an application. It can be used to specify more than one application in a single collection.

  -b Turn off the splash screen

  -p The next four arguments are used to specify the splash screen's image, title, number of files, and depth of files. This can only be used in conjunction with the -u or the -a flags.

  -u, --non-unitized This is used to specify a non-unit startup.

  -v, --version Prints the version information

  -- This flag indicates that this phase of commandline arguments is finished. The rest of the command line arguments are passed to the application.

• Splash Screen: After the command line arguments the splash screen is opened.

  The splash screen is specified in the info.ss file, if you use the -A flag. See the info.ss section. You can specify the splash screen on the command line with the -p and -b flags. The latter technique only works if you are using either the -a or the -u option.

  The splash screen will always show a progress bar, indicating how many files have been loaded. If you evaluate this expression:

  (wx:write-resource "mred" "splashMessages" 1 (wx:find-path 'setup-file))

  it will also show the file names as they are being loaded. This is useful for developers of applications, but not very useful for clients.

  The first time the splash screen is opened, it guesses the number of files loaded and the depth of the recursive loads (for unitized applications using the -A flag, the info file specifies those initial guesses). After the application starts up, MrEd records the those numbers, for future uses of the splash screen. For unitized applications, the numbers are keyed on the applications name, and for non-unitized applications, only one set of numbers are saved, so two different non-unitized application's numbers will conflict with each other.

• Application Startup: After the splash screen is opened, the application is created. Depending on the command line flags specified earlier, one of two different actions will happen here. The default is the ``unspecified application'' case.

  Unitized application: In this case, the info.ss file is loaded and it's contents used as described in the unitized application section. Any remaining command-line flags are passed to that application.

  Non-unitized application and unspecified application: In this case, the following command line flags are interpreted:

  -d The next argument is treated as a Scheme filename and is load/cd'd. The -d flag can be specified many times to load many files.

  -e The next argument is evaluated as a Scheme expression. The -e flag can be specified many times to load many files.

  -f The next argument is treated as a Scheme filename and is loaded. The -f flag can be specified many times to load many files.

  -q The user setup section is skipped

  Any other command line arguments are treated as filenames; they will be opened in editor buffers.

  These command line flags must come after the -- flag, described above.

• User Setup: Finally the system mred:user-setup loads a user-specific startup file if it exists:
  • Under X Windows, .mredrc is loaded from the user's home directory.
  • Under Windows, if the HOMEDRIVE and HOMEPATH environment variables are defined, %HOMEDRIVE%\%HOMEPATH%\mredrc.ss is loaded, otherwise mredrc.ss is loaded from the MrEd application's directory.
  • Under MacOS, mredrc.ss is loaded from the preferences folder.

  The user setup is not always loaded last. In general it is loaded when all of the variables that begin with mred: are defined. So, if you are using the -u flag, the user setup is loaded before any of the files on the command line are loaded and if you are not using the -u flag, the user setup is loaded after all of the command line arguments have been processed.

If the system is not found, or if there is an uncaught error while the system is loaded, then the load is aborted and a plain text editing window is opened.