diff lisp/glyphs.el @ 412:697ef44129c6 r21-2-14

Import from CVS: tag r21-2-14
author cvs
date Mon, 13 Aug 2007 11:20:41 +0200
parents 501cfd01ee6d
children
line wrap: on
line diff
--- a/lisp/glyphs.el	Mon Aug 13 11:19:22 2007 +0200
+++ b/lisp/glyphs.el	Mon Aug 13 11:20:41 2007 +0200
@@ -1,7 +1,7 @@
 ;;; glyphs.el --- Lisp interface to C glyphs
 
 ;; Copyright (C) 1994, 1997 Free Software Foundation, Inc.
-;; Copyright (C) 1995, 1996, 2000 Ben Wing.
+;; Copyright (C) 1995, 1996 Ben Wing.
 
 ;; Author: Chuck Thompson <cthomp@cs.uiuc.edu>, Ben Wing <ben@xemacs.org>
 ;; Maintainer: XEmacs Development Team
@@ -26,287 +26,27 @@
 
 ;;; Synched up with: Not in FSF.
 
-;;; Authorship:
-
-;; Prototype created 1995 by Chuck Thompson.
-;; Completely rewritten by Ben Wing, 1995.
-;; Various cleanups (esp. doc strings) by Ben Wing, May 2000.
-
 ;;; Commentary:
 
 ;; This file is dumped with XEmacs.
 
 ;;; Code:
 
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; image specifiers
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; font specifiers
 
 (defun make-image-specifier (spec-list)
   "Return a new `image' specifier object with the specification list SPEC-LIST.
 SPEC-LIST can be a list of specifications (each of which is a cons of a
 locale and a list of instantiators), a single instantiator, or a list
 of instantiators.  See `make-specifier' for more information about
-specifiers.
-
-An image specifier is used for images (pixmaps, widgets and the like).
-It is used to describe the actual image in a glyph.  It is instanced
-as an image-instance.  Note that \"image\" as used in XEmacs does not
-actually refer to what the term \"image\" normally means (a picture,
-e.g. in .GIF or .JPG format, and called a \"pixmap\" in XEmacs), but
-includes all types of graphical elements, including pixmaps, widgets
-\(buttons, sliders, text fields, etc.) and even strings of text.
-
-Note that, in practice, you rarely, if ever, need to actually create
-an image specifier! (The function `make-image-specifier' exists mainly
-for completeness.) Pretty much the only use for image specifiers is to
-control how glyphs are displayed, and the image specifier associated
-with a glyph (the `image' property of a glyph) is created
-automatically when a glyph is created (see `make-glyph') and need not
-\(and cannot, for that matter) ever be changed.  In fact, the design
-decision to create a separate image specifier type, rather than make
-glyphs themselves be specifiers, is debatable -- the other properties
-of glyphs are rarely used and could conceivably have been incorporated
-into the glyph's instantiator.  The rarely used glyph types (buffer,
-pointer, icon) could also have been incorporated into the instantiator.
-
-Image instantiators come in many formats: `xbm', `xpm', `gif', `jpeg',
-etc.  This describes the format of the data describing the image.  The
-resulting image instances also come in many types -- `mono-pixmap',
-`color-pixmap', `text', `pointer', etc.  This refers to the behavior of
-the image and the sorts of places it can appear. (For example, a
-color-pixmap image has fixed colors specified for it, while a
-mono-pixmap image comes in two unspecified shades \"foreground\" and
-\"background\" that are determined from the face of the glyph or
-surrounding text; a text image appears as a string of text and has an
-unspecified foreground, background, and font; a pointer image behaves
-like a mono-pixmap image but can only be used as a mouse pointer
-\[mono-pixmap images cannot be used as mouse pointers]; etc.) It is
-important to keep the distinction between image instantiator format and
-image instance type in mind.  Typically, a given image instantiator
-format can result in many different image instance types (for example,
-`xpm' can be instanced as `color-pixmap', `mono-pixmap', or `pointer';
-whereas `cursor-font' can be instanced only as `pointer'), and a
-particular image instance type can be generated by many different
-image instantiator formats (e.g.  `color-pixmap' can be generated by `xpm',
-`gif', `jpeg', etc.).
-
-See `make-image-instance' for a more detailed discussion of image
-instance types.
-
-An image instantiator should be a string or a vector of the form
-
- [FORMAT :KEYWORD VALUE ...]
-
-i.e. a format symbol followed by zero or more alternating keyword-value
-pairs.  FORMAT should be one of
-
-'nothing
-   Don't display anything; no keywords are valid for this.
-   Can only be instanced as `nothing'.
-'string
-   Display this image as a text string.  Can only be instanced
-   as `text', although support for instancing as `mono-pixmap'
-   and `color-pixmap' should be added.
-'formatted-string
-   Display this image as a text string, with replaceable fields;
-   not currently implemented. (It is, instead, equivalent to `string'.)
-'xbm
-   An X bitmap; only if X or MS Windows support was compiled into this
-   XEmacs.  Can be instanced as `mono-pixmap', `color-pixmap', or `pointer'.
-'xpm
-   An XPM pixmap; only if XPM support was compiled into this XEmacs.
-   Can be instanced as `color-pixmap', `mono-pixmap', or `pointer'.
-'xface
-   An X-Face bitmap, used to encode people's faces in e-mail messages;
-   only if X-Face support was compiled into this XEmacs.  Can be
-   instanced as `mono-pixmap', `color-pixmap', or `pointer'.
-'gif
-   A GIF87 or GIF89 image; only if GIF support was compiled into this
-   XEmacs.  NOTE: only the first frame of animated gifs will be displayed.
-   Can be instanced as `color-pixmap'.
-'jpeg
-   A JPEG image; only if JPEG support was compiled into this XEmacs.
-   Can be instanced as `color-pixmap'.
-'png
-   A PNG image; only if PNG support was compiled into this XEmacs.
-   Can be instanced as `color-pixmap'.
-'tiff
-   A TIFF image; only if TIFF support was compiled into this XEmacs.
-   Can be instanced as `color-pixmap'.
-'bmp
-   A MS Windows BMP image; only if MS Windows support was compiled into
-   this XEmacs.  Can be instanced as `color-pixmap'.
-'cursor-font
-   One of the standard cursor-font names, such as \"watch\" or
-   \"right_ptr\" under X.  Under X, this is, more specifically, any
-   of the standard cursor names from appendix B of the Xlib manual
-   [also known as the file <X11/cursorfont.h>] minus the XC_ prefix.
-   On other window systems, the valid names will be specific to the
-   type of window system.  Can only be instanced as `pointer'.
-'mswindows-resource
-   An MS Windows pointer resource.  Specifies a resource to retrieve
-   directly from the system (an OEM resource) or from a file, particularly
-   an executable file.  If the resource is to be retrieved from a file, use
-   :file and optionally :resource-id.  Otherwise use :resource-id.  Always
-   specify :resource-type to specify the type (cursor, bitmap or icon) of
-   the resource.  Possible values for :resource-id are listed below.  Can
-   be instanced as `pointer' or `color-pixmap'.
-'font
-   A glyph from a font; i.e. the name of a font, and glyph index into it
-   of the form \"FONT fontname index [[mask-font] mask-index]\".
-   Currently can only be instanced as `pointer', although this should
-   probably be fixed.
-'subwindow
-   An embedded windowing system window.  Can only be instanced as
-   `subwindow'.
-'button
-   A button widget; either a push button, radio button or toggle button.
-   Can only be instanced as `widget'.
-'combo-box
-   A drop list of selectable items in a widget, for editing text.
-   Can only be instanced as `widget'.
-'edit-field
-   A text editing widget.  Can only be instanced as `widget'.
-'label
-   A static, text-only, widget; for displaying text.  Can only be instanced
-   as `widget'.
-'layout
-   A widget for controlling the positioning of children underneath it.
-   Through the use of nested layouts, a widget hierarchy can be created
-   which can have the appearance of any standard dialog box or similar
-   arrangement; all of this is counted as one \"glyph\" and could appear
-   in many of the places that expect a single glyph.  Can only be instanced
-   as `widget'.
-'native-layout
-   The native version of a layout widget.  #### Document me better!
-   Can only be instanced as `widget'.
-'progress-gauge
-   A sliding widget, for showing progress.  Can only be instanced as
-   `widget'.
-'tab-control
-   A tab widget; a series of user selectable tabs.  Can only be instanced
-   as `widget'.
-'tree-view
-   A folding widget.  Can only be instanced as `widget'.
-'scrollbar
-   A scrollbar widget.  Can only be instanced as `widget'.
-'autodetect
-   XEmacs tries to guess what format the data is in.  If X support
-   exists, the data string will be checked to see if it names a filename.
-   If so, and this filename contains XBM or XPM data, the appropriate
-   sort of pixmap or pointer will be created. [This includes picking up
-   any specified hotspot or associated mask file.] Otherwise, if `pointer'
-   is one of the allowable image-instance types and the string names a
-   valid cursor-font name, the image will be created as a pointer.
-   Otherwise, the image will be displayed as text.  If no X support
-   exists, the image will always be displayed as text.  Can be instanced as
-   `mono-pixmap', `color-pixmap', `pointer', or `text'.
-'inherit
-   Inherit from the background-pixmap property of a face.  Can only be
-   instanced as `mono-pixmap'.
-
-The valid keywords are:
-
-:data
-   Inline data.  For most formats above, this should be a string.  For
-   XBM images, this should be a list of three elements: width, height, and
-   a string of bit data.  This keyword is valid for all of the bitmap/pixmap
-   formats, as well as `string', `formatted-string', `font', `cursor-font',
-   and `autodetect'.
-:file
-   Data is contained in a file.  The value is the name of this file.
-   If both :data and :file are specified, the image is created from
-   what is specified in :data and the string in :file becomes the
-   value of the `image-instance-file-name' function when applied to
-   the resulting image-instance.  This keyword is valid for all of the
-   bitmap/pixmap formats as well as `mswindows-resource'.
-:foreground
-:background
-   For `xbm', `xface', `cursor-font', `widget' and `font'.  These keywords
-   allow you to explicitly specify foreground and background colors.
-   The argument should be anything acceptable to `make-color-instance'.
-   This will cause what would be a `mono-pixmap' to instead be colorized
-   as a two-color color-pixmap, and specifies the foreground and/or
-   background colors for a pointer instead of black and white.
-:mask-data
-   For `xbm' and `xface'.  This specifies a mask to be used with the
-   bitmap.  The format is a list of width, height, and bits, like for
-   :data.
-:mask-file
-   For `xbm' and `xface'.  This specifies a file containing the mask data.
-   If neither a mask file nor inline mask data is given for an XBM image,
-   and the XBM image comes from a file, XEmacs will look for a mask file
-   with the same name as the image file but with \"Mask\" or \"msk\"
-   appended.  For example, if you specify the XBM file \"left_ptr\"
-   [usually located in \"/usr/include/X11/bitmaps\"], the associated
-   mask file \"left_ptrmsk\" will automatically be picked up.
-:hotspot-x
-:hotspot-y
-   For `xbm' and `xface'.  These keywords specify a hotspot if the image
-   is instantiated as a `pointer'.  Note that if the XBM image file
-   specifies a hotspot, it will automatically be picked up if no
-   explicit hotspot is given.
-:color-symbols
-   Only for `xpm'.  This specifies an alist that maps strings
-   that specify symbolic color names to the actual color to be used
-   for that symbolic color (in the form of a string or a color-specifier
-   object).  If this is not specified, the contents of `xpm-color-symbols'
-   are used to generate the alist.
-:resource-id
-   Only for `mswindows-resource'.  This must be either an integer (which
-   directly specifies a resource number) or a string.  Valid strings are
-
-   -- For bitmaps:
-
-   \"close\", \"uparrow\", \"dnarrow\", \"rgarrow\", \"lfarrow\",
-   \"reduce\", \"zoom\", \"restore\", \"reduced\", \"zoomd\",
-   \"restored\", \"uparrowd\", \"dnarrowd\", \"rgarrowd\", \"lfarrowd\",
-   \"mnarrow\", \"combo\", \"uparrowi\", \"dnarrowi\", \"rgarrowi\",
-   \"lfarrowi\", \"size\", \"btsize\", \"check\", \"checkboxes\", and
-   \"btncorners\".
-
-   -- For cursors:
-
-   \"normal\", \"ibeam\", \"wait\", \"cross\", \"up\", \"sizenwse\",
-   \"sizenesw\", \"sizewe\", \"sizens\", \"sizeall\", and \"no\".
-
-   -- For icons:
-
-   \"sample\", \"hand\", \"ques\", \"bang\", \"note\", and \"winlogo\".
-:resource-type
-   Only for `mswindows-resource'.  This must be a symbol, either `cursor',
-   `icon', or `bitmap', specifying the type of resource to be retrieved.
-:face
-   Only for `inherit'.  This specifies the face to inherit from.
-   For widgets this also specifies the face to use for display. It defaults
-   to gui-element-face.
-
-Keywords accepted as menu item specs are also accepted by widgets.
-These are `:selected', `:active', `:suffix', `:keys', `:style',
-`:filter', `:config', `:included', `:key-sequence', `:accelerator',
-`:label' and `:callback'.
-
-If instead of a vector, the instantiator is a string, it will be
-converted into a vector by looking it up according to the specs in the
-`console-type-image-conversion-list' (q.v.) for the console type of
-the domain (usually a window; sometimes a frame or device) over which
-the image is being instantiated.
-
-If the instantiator specifies data from a file, the data will be read
-in at the time that the instantiator is added to the image (which may
-be well before when the image is actually displayed), and the
-instantiator will be converted into one of the inline-data forms, with
-the filename retained using a :file keyword.  This implies that the
-file must exist when the instantiator is added to the image, but does
-not need to exist at any other time (e.g. it may safely be a temporary
-file).
-"
+specifiers."
   (make-specifier-and-init 'image spec-list))
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; glyphs
 
 (defconst built-in-glyph-specifiers
   '(image contrib-p baseline)
-  "A list of the built-in glyph properties that are specifiers.")
+  "A list of the built-in face properties that are specifiers.")
 
 (defun glyph-property (glyph property &optional locale)
   "Return GLYPH's value of PROPERTY in LOCALE.
@@ -547,7 +287,7 @@
   "Change the image of GLYPH in LOCALE.
 
 SPEC should be an instantiator (a string or vector; see
-  `make-image-specifier' for a description of possible values here),
+  `image-specifier-p' for a description of possible values here),
   a list of (possibly tagged) instantiators, an alist of specifications
   (each mapping a locale to an instantiator list), or an image specifier
   object.
@@ -640,162 +380,20 @@
   (set-glyph-property glyph 'baseline spec locale tag-set how-to-add))
 
 (defun make-glyph (&optional spec-list type)
-  "Create a new glyph of type TYPE.
-
-A glyph in XEmacs does NOT refer to a single unit of textual display (the
-XEmacs term for this is \"rune\"), but rather is an object encapsulating
-a graphical element, such as an image or widget (an element such as a
-button or text field; \"widget\" is the term for this under X Windows,
-and it's called a \"control\" under MS Windows).  This graphical element
-could appear in a buffer, a margin, a gutter, or a toolbar, or as a mouse
-pointer or an icon, for example.
-
-Creating a glyph using `make-glyph' does not specify *where* the glyph
-will be used, but it does specify *what* the glyph will look like.  In
-particular, SPEC-LIST is used to specify this, and it's used to
-initialize the glyph's `image' property, which is an image
-specifier. (Note that \"image\" as used in the context of a glyph's
-`image' property or in the terms \"image specifier\", \"image
-instantiator\", or \"image instance\" does not refer to what people
-normally think of as an image (which in XEmacs is called a
-\"pixmap\"), but to any graphical element -- a pixmap, a widget, or
-even a block of text, when used in the places that call for a glyph.)
-The format of the SPEC-LIST is typically an image instantiator (a
-string or a vector; see `make-image-specifier' for a detailed description
-of the valid image instantiators), but can also be a list of such
-instantiators (each one in turn is tried until an image is
-successfully produced), a cons of a locale (frame, buffer, etc.)  and
-an instantiator, a list of such conses, or any other form accepted by
-`canonicalize-spec-list'.
+  "Return a new `glyph' object of type TYPE.
 
-If you're not familiar with specifiers, you should be in order to
-understand how glyphs work.  The clearest introduction to specifiers
-is in the Lispref manual, available under Info. (Choose
-Help->Info->Info Contents on the menubar or type \\[info].) You can
-also see `make-specifier' for a capsule summary.  What's important to
-keep in mind is that a specifier lets you set a different value for
-any particular buffer, window, frame, device, or console.  This allows
-for a great deal of flexibility; in particular, only one global glyph
-needs to exist for a particular purpose (e.g. the icon used to represent
-an iconified frame, the mouse pointer used over particular areas of a
-frame, etc.), and in these cases you do not create your own glyph, but
-rather modify the existing one.
-
-As well as using SPEC-LIST to initialize the glyph, you can set
-specifications using `set-glyph-image'.  Note that, due to a possibly
-questionable historical design decision, a glyph itself is not
-actually a specifier, but rather is an object containing an image
-specifier (as well as other, seldom-used properties).  Therefore, you
-cannot set or access specifications for the glyph's image by directly
-using `set-specifier', `specifier-instance' or the like on the glyph;
-instead use them on `(glyph-image GLYPH)' or use the convenience
-functions `set-glyph-image', `glyph-image-instance', and
-`glyph-image'.
-
-Once you have created a glyph, you specify where it will be used as follows:
-
--- To insert a glyph into a buffer, create an extent in the buffer and then
-   use `set-extent-begin-glyph' or `set-extent-end-glyph' to set a glyph
-   to be displayed at the corresponding edge of the extent. (It is common
-   to create zero-width extents for this purpose.)
-
--- To insert a glyph into the left or right margin of a buffer, first
-   make sure the margin is visible by setting a value for the specifiers
-   `left-margin-width' or `right-margin-width'. (Not strictly necessary
-   when using margin glyphs with layout policy `whitespace'.) Then follow
-   the same procedure above for inserting a glyph in a buffer, and then
-   set a non-default layout policy for the glyph using
-   `set-extent-begin-glyph-layout' or `set-extent-end-glyph-layout'.
-   Alternatively, use the high-level annotations API (see
-   `make-annotation'). (In point of fact, you can also use the annotations
-   API for glyphs in a buffer, by setting a layout policy of `text'.)
-
--- To insert a glyph into the modeline, just put the glyph directly as
-   one of the modeline elements. (Unfortunately you can't currently
-   put a begin glyph or end glyph on one of the modeline extents --
-   they're ignored.)
+TYPE should be one of `buffer' (used for glyphs in an extent, the modeline,
+the toolbar, or elsewhere in a buffer), `pointer' (used for the mouse-pointer),
+or `icon' (used for a frame's icon), and defaults to `buffer'.
 
--- To insert a glyph into a toolbar, specify it as part of a toolbar
-   instantiator (typically set on the specifier `default-toolbar').
-   See `default-toolbar' for more information. (Note that it is standard
-   practice to use a symbol in place of the glyph list in the toolbar
-   instantiator; the symbol is evalled to get the glyph list.  This
-   facilitates both creating the toolbar instantiator and modifying
-   individual glyphs in a toolbar later on.  For example, you can
-   change the way that the Mail toolbar button looks by modifying the
-   value of the variable `toolbar-mail-icon' (in general, `toolbar-*-icon')
-   and then calling `(set-specifier-dirty-flag default-toolbar)'.
-   (#### Unfortunately this doesn't quite work the way it should; the
-   change will appear in new frames, but not existing ones.
-
--- To insert a glyph into a gutter, create or modify a gutter instantiator
-   (typically set on the specifier `default-gutter').  Gutter instantiators
-   consist of strings or lists of strings, so to insert a glyph, create an
-   extent over the string, and use `set-extent-begin-glyph' or
-   `set-extent-end-glyph' to set a glyph to be displayed at the corresponding
-   edge of the extent, just like for glyphs in a buffer.
-
--- To use a glyph as the icon for a frame, you do not actually create a new
-   glyph; rather, you change the specifications for the existing glyph
-   `frame-icon-glyph'. (Remember that, because of the specifier nature of
-   glyphs, you can set different values for any particular buffer or frame.)
-
--- To use a glyph as the mouse pointer, in general you do not create a
-   new glyph, but rather you change the specifications of various existing
-   glyphs, such as `text-pointer-glyph' for the pointer used over text,
-   `modeline-pointer-glyph' for the pointer used over the modeline, etc.
-   Do an apropos over `*-pointer-glyph' to find all of them. (Note also
-   that you can temporarily set the mouse pointer to some specific shape
-   by using `set-frame-pointer', which takes an image instace, as obtained
-   from calling `glyph-image-instance' on a glyph of type `pointer' --
-   either one of the above-mentioned variables or one you created yourself.
-   (See below for what it means to create a glyph of type `pointer'.)
-   This pointer will last only until the next mouse motion event is
-   processed or certain other things happen, such as creating or deleting
-   a window. (In fact, the above-mentioned pointer glyph variables are
-   implemented as part of the default handler for mouse motion events.
-   If you want to customize this behavior, take a look at `mode-motion-hook',
-   or `mouse-motion-handler' if you really want to get low-level.)
-
--- To use a glyph to control the shape of miscellaneous redisplay effects
-   such as the truncation and continuation markers, set the appropriate
-   existing glyph variables, as for icons and pointers above.  See
-   `continuation-glyph', `control-arrow-glyph', `hscroll-glyph',
-   `invisible-text-glyph', `octal-escape-glyph', and `truncation-glyph'.
-   See also `overlay-arrow-string', an odd redisplay leftover which can
-   be set to a glyph you created, and will cause the glyph to be displayed
-   on top of the text position specified in the marker stored in
-   `overlay-arrow-position'.
-
--- To use a glyph in a display table (i.e. to control the appearance of
-   any individual character), create the appropriate character glyphs
-   and then set a specification for the specifier `current-display-table',
-   which controls the appearance of characters.  You can also set an
-   overriding display table for use with text displayed in a particular
-   face; see `set-face-display-table' and `make-display-table'.
-   #### Note: Display tables do not currently support general Mule
-   characters.  They will be overhauled at some point to support this
-   and to provide other features required under Mule.
-
--- To use a glyph as the background pixmap of a face: Note that the
-   background pixmap of a face is actually an image specifier -- probably
-   the only place in XEmacs where an image specifier occurs outside of
-   a glyph.  Similarly to how the glyph's image specifier works, you
-   don't create your own image specifier, but rather add specifications
-   to the existing one (using `set-face-background-pixmap').  Note that
-   the image instance that is generated in order to actually display the
-   background pixmap is of type `mono-pixmap', meaning that it's a two-color
-   image and the foreground and background of the image get filled in with
-   the corresponding colors from the face.
-
-It is extremely rare that you will ever have to specify a value for TYPE,
-which should be one of `buffer' (used for glyphs in an extent, the modeline,
-the toolbar, or elsewhere in a buffer), `pointer' (used for the mouse-pointer),
-or `icon' (used for a frame's icon), and defaults to `buffer'.  The only cases
-where it needs to be specified is when creating icon or pointer glyphs, and
-in both cases the necessary glyphs have already been created at startup and
-are accessed through the appropriate variables, e.g. `text-pointer-glyph'
-(or in general, `*-pointer-glyph') and `frame-icon-glyph'."
+SPEC-LIST is used to initialize the glyph's image.  It is typically an
+image instantiator (a string or a vector; see `image-specifier-p' for
+a detailed description of the valid image instantiators), but can also
+be a list of such instantiators (each one in turn is tried until an
+image is successfully produced), a cons of a locale (frame, buffer, etc.)
+and an instantiator, a list of such conses, or any other form accepted
+by `canonicalize-spec-list'.  See `make-specifier' for more information
+about specifiers."
   (let ((glyph (make-glyph-internal type)))
     (and spec-list (set-glyph-image glyph spec-list))
     glyph))
@@ -814,22 +412,38 @@
 
 (defun make-pointer-glyph (&optional spec-list)
   "Return a new `pointer-glyph' object with the specification list SPEC-LIST.
+
 This is equivalent to calling `make-glyph', specifying a type of `pointer'.
-See `make-glyph' for more information.
 
-It is extremely unlikely that you will ever need to create a pointer glyph.
-Instead, you probably want to be calling `set-glyph-image' on an existing
-glyph, e.g. `text-pointer-glyph'."
+SPEC-LIST is used to initialize the glyph's image.  It is typically an
+image instantiator (a string or a vector; see `image-specifier-p' for
+a detailed description of the valid image instantiators), but can also
+be a list of such instantiators (each one in turn is tried until an
+image is successfully produced), a cons of a locale (frame, buffer, etc.)
+and an instantiator, a list of such conses, or any other form accepted
+by `canonicalize-spec-list'.  See `make-specifier' for more information
+about specifiers.
+
+You can also create a glyph with an empty SPEC-LIST and add image
+instantiators afterwards using `set-glyph-image'."
   (make-glyph spec-list 'pointer))
 
 (defun make-icon-glyph (&optional spec-list)
   "Return a new `icon-glyph' object with the specification list SPEC-LIST.
+
 This is equivalent to calling `make-glyph', specifying a type of `icon'.
-See `make-glyph' for more information.
 
-It is extremely unlikely that you will ever need to create a icon glyph.
-Instead, you probably want to be calling `set-glyph-image' on
-`frame-icon-glyph'."
+SPEC-LIST is used to initialize the glyph's image.  It is typically an
+image instantiator (a string or a vector; see `image-specifier-p' for
+a detailed description of the valid image instantiators), but can also
+be a list of such instantiators (each one in turn is tried until an
+image is successfully produced), a cons of a locale (frame, buffer, etc.)
+and an instantiator, a list of such conses, or any other form accepted
+by `canonicalize-spec-list'.  See `make-specifier' for more information
+about specifiers.
+
+You can also create a glyph with an empty SPEC-LIST and add image
+instantiators afterwards using `set-glyph-image'."
   (make-glyph spec-list 'icon))
 
 (defun nothing-image-instance-p (object)
@@ -854,12 +468,9 @@
   "Return t if OBJECT is an image instance of type `pointer'."
   (and (image-instance-p object) (eq 'pointer (image-instance-type object))))
 
-(defun widget-image-instance-p (object)
-  "Return t if OBJECT is an image instance of type `widget'."
-  (and (image-instance-p object) (eq 'widget (image-instance-type object))))
-
 (defun subwindow-image-instance-p (object)
-  "Return t if OBJECT is an image instance of type `subwindow'."
+  "Return t if OBJECT is an image instance of type `subwindow'.
+Subwindows are not implemented in this version of XEmacs."
   (and (image-instance-p object) (eq 'subwindow (image-instance-type object))))
 
 ;;;;;;;;;; the built-in glyphs