Don't determine whether to call general device-type code at startup, rather decide in the device-specific code itself. lisp/ChangeLog addition: 2008-07-07 Aidan Kehoe <kehoea@parhasard.net> Patch to make it up to the device-specific code whether various Lisp functions should be called during device creation, not relying on the startup code to decide this. Also, rename initial-window-system to initial-device-type (which makes more sense in this scheme), always set it. * startup.el (command-line): Use initial-device-type, not initial-window-system; just call #'make-device, leave the special behaviour to be done the first time a console type is initialised to be decided on by the respective console code. * x-init.el (x-app-defaults-directory): Declare that it should be bound. (x-define-dead-key): Have the macro take a DEVICE argument. (x-initialize-compose): Have the function take a DEVICE argument, and use it when checking if various keysyms are available on the keyboard. (x-initialize-keyboard): Have the function take a DEVICE argument, allowing device-specific keyboard initialisation. (make-device-early-x-entry-point-called-p): New. (make-device-late-x-entry-point-called-p): New. Rename pre-x-win-initted, x-win-initted. (make-device-early-x-entry-point): Rename init-pre-x-win, take the call to make-x-device out (it should be called from the device-creation code, not vice-versa). (make-device-late-x-entry-point): Rename init-post-x-win, have it take a DEVICE argument, use that DEVICE argument when working out what device-specific things need doing. Don't use create-console-hook in core code. * x-win-xfree86.el (x-win-init-xfree86): Take a DEVICE argument; use it. * x-win-sun.el (x-win-init-sun): Take a DEVICE argument; use it. * mule/mule-x-init.el: Remove #'init-mule-x-win, an empty function. * tty-init.el (make-device-early-tty-entry-point-called-p): New. Rename pre-tty-win-initted. (make-device-early-tty-entry-point): New. Rename init-pre-tty-win. (make-frame-after-init-entry-point): New. Rename init-post-tty-win to better reflect when it's called. * gtk-init.el (gtk-early-lisp-options-file): New. Move this path to a documented variable. (gtk-command-switch-alist): Wrap the docstring to fewer than 79 columns. (make-device-early-gtk-entry-point-called-p): New. (make-device-late-gtk-entry-point-called-p): New. Renamed gtk-pre-win-initted, gtk-post-win-initted to these. (make-device-early-gtk-entry-point): New. (make-device-late-gtk-entry-point): New. Renamed init-pre-gtk-win, init-post-gtk-win to these. Have make-device-late-gtk-entry-point take a device argument, and use it; have make-device-early-gtk-entry-point load the GTK-specific startup code, instead of doing that in C. (init-gtk-win): Deleted, functionality moved to the GTK device creation code. (gtk-define-dead-key): Have it take a DEVICE argument; use this argument. (gtk-initialize-compose): Ditto. * coding.el (set-terminal-coding-system): Correct the docstring; the function isn't broken. src/ChangeLog addition: 2008-07-07 Aidan Kehoe <kehoea@parhasard.net> Patch to make it up to the device-specific code whether various Lisp functions should be called during device creation, not relying on the startup code to decide this. Also, rename initial-window-system to initial-device-type (which makes more sense in this scheme), always set it. * redisplay.c (Vinitial_device_type): New. (Vinitial_window_system): Removed. Rename initial-window-system to initial-device type, making it a stream if we're noninteractive. Update its docstring. * device-x.c (Qmake_device_early_x_entry_point, Qmake_device_late_x_entry_point): New. Rename Qinit_pre_x_win, Qinit_post_x_win. (x_init_device): Call #'make-device-early-x-entry-point earlier, now we rely on it to find the application class and the app-defaults directory. (x_finish_init_device): Call #'make-device-late-x-entry-point with the created device. (Vx_app_defaults_directory): Always make this available, to simplify code in x-init.el. * device-tty.c (Qmake_device_early_tty_entry_point): New. Rename Qinit_pre_tty_win, rename Qinit_post_tty_win and move to frame-tty.c as Qmake_frame_after_init_entry_point. (tty_init_device): Call #'make-device-early-tty-entry-point before doing anything. * frame-tty.c (Qmake_frame_after_init_entry_point): New. * frame-tty.c (tty_after_init_frame): Have it call the better-named #'make-frame-after-init-entry-point function instead of #'init-post-tty-win (since it's called after frame, not device, creation). * device-msw.c (Qmake_device_early_mswindows_entry_point, Qmake_device_late_mswindows_entry_point): New. Rename Qinit_pre_mswindows_win, Qinit_post_mswindows_win. (mswindows_init_device): Call #'make-device-early-mswindows-entry-point here, instead of having its predecessor call us. (mswindows_finish_init_device): Call #'make-device-early-mswindows-entry-point, for symmetry with the other device types (though it's an empty function). * device-gtk.c (Qmake_device_early_gtk_entry_point, Qmake_device_late_gtk_entry_point): New. Rename Qinit_pre_gtk_win, Qinit_post_gtk_win. (gtk_init_device): Call #'make-device-early-gtk-entry-point; don't load ~/.xemacs/gtk-options.el ourselves, leave that to lisp. (gtk_finish_init_device): Call #'make-device-late-gtk-entry-point with the created device as an argument.

Package distributions may be placed in this directory.
If present and a package-path is configured, packages can be installed
using the top-level Makefile.

To configure the package path, use the --with-late-packages option to
configure, which specifies a single directory in which to install the
xemacs-packages and mule-packages hierarchies provided.  If this is null,
or contains a Unix-style search path (i.e., a colon is present in the
argument of the --with-late-packages option), you will have to install
the packages by hand.

To find out if a distribution includes bundled packages, type

    make check-available-packages

There are three Make targets that may be available depending on the package
sets supplied.

    make install-bootstrap-packages
        Install a selected set of packages sufficient to support
        downloading and installing packages via the M-x list-packages
        interface.  Chose this if you want to be able to install the
        latest version of each package immediately.

    make install-nomule-packages
        Install the full distribution of packages that do not require a
        Mule-enabled XEmacs.  Choose this package if you don't have a
        Mule-enabled XEmacs and want the convenience of a single-command
        installation.  You can add or update packages via M-x list-packages
        at any time.

    make install-all-packages
        Install the full distribution of packages, including those requiring
        a Mule-enabled XEmacs.  Choose this package if you have a Mule-
        enabled XEmacs and want the convenience of a single-command
        installation.  You can add or update packages via M-x list-packages
        at any time.

DISTRIBUTOR'S NOTE: you may choose what packages you wish to include in
bootstrap.tar.gz, but to make list-packages work you need to include at
least xemacs-base, dired, and efs.  The tarball should unpack directly as
an xemacs-packages tree (and optionaly, a mule-packages tree.  Also, if
either of xemacs-sumo.tar.gz or xemacs-mule-sumo.tar.gz is provided, the
other should be as well.

If packages are not available with the distribution, you can get them at

    ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz
    ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz
    http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/bootstrap.tar.gz

and place them in the same directory as this file.  You can also make your
own bootstrap.tar.gz by creating a directory xemacs-packages, then
untarring the packages of your choice into that directory, and tarring the
whole thing up with "tar czf bootstrap.tar.gz xemacs-packages".  (If you
wish to include mule-packages, you should place them in mule-packages as
a sibling of xemacs-packages.)

This facility currently does not support installations which configure
the --with-early-packages, --with-late-packages, or --with-last-packages
options.

This facility currently will not overwrite an existing package
installation, not even if a whole hierarchy (usually the mule-packages)
is missing.  In particular, you cannot use this feature to add the
mule-packages to a package installation which lacks them, even if the
hierarchy is missing, or the xemacs-packages hierarchy was installed
this way.  Nor can you "upgrade" a bootstrap installation to a full
installation.  If you wish to do any of these things you will need to
remove the existing hierarchies.