lots of doc updates, some glyph changes

here i made lots and lots and lots of changes to various doc strings, esp for specifiers, glyphs, and the like. the doc strings should now be more complete than what's in the elisp manual, and i'd appreciate it if someone (martin, hrvoje, yoshiki?) could texinfo them appropriately. also, in emacs.c, i put in the timeline from the internals manual, for easy reference when writing authorship comments and synching. i'm missing the most recent releases of xemacs and gnu emacs; it would be nice if someone could fill them in (in both places). one policy change here is that the documentation for all specifiers is now in `make-*-specifier' rather than in the specifier predicate. this is in keeping with the way things are done elsewhere in xemacs and makes the most intuitive sense to me. i also did some cleanups of the glyph code, and (Andy pay attention :-) fixed some very real crashes that were hitting me at window and frame closure. some other people may have hit them, too. andy, i haven't fixed the problem with the gutter being wrong if you visit a couple of C files and then split the window, but i know exactly what's going on and i'll send a patch in the next commit. hrvoje, i noticed that you went and implemented much of what i proposed should be done to display tables. this is way cool, and it's going to save me a lot of time when i get there -- as part of unicode support, i need really powerful display tables, and you've gone a long way towards implementation. ChangeLog: lib-src/ChangeLog: lisp/ChangeLog: ＠＠ -1,5 1,61 ＠＠ * faces.el (set-face-property): * faces.el (set-face-font): * faces.el (set-face-foreground): * faces.el (set-face-background): * faces.el (set-face-background-pixmap): * faces.el (set-face-underline-p): * faces.el (set-face-strikethru-p): * faces.el (set-face-highlight-p): * faces.el (set-face-dim-p): * faces.el (set-face-blinking-p): * faces.el (set-face-reverse-p): doc string changes. * glyphs.el: * glyphs.el (make-image-specifier): * glyphs.el (glyph-property): * glyphs.el (set-glyph-image): * glyphs.el (make-glyph): * glyphs.el (make-pointer-glyph): * glyphs.el (make-icon-glyph): * glyphs.el (widget-image-instance-p): New. authorship info, lots of doc changes. New predicate, inadvertently omitted. the general principle with specifier docs is now that the description of instantiators should go with the make-foo-specifier fun's doc string, rather than in foo-specifier-p. this follows conventions elsewhere in XEmacs and in general is a lot more obvious of a place to look. sometimes the make-foo-specifier function needs to be created in the process. * gutter.el: * gutter.el (make-gutter-specifier): New. * gutter.el (make-gutter-size-specifier): New. * gutter.el (make-gutter-visible-specifier): New. specifier doc updates according to the conventions specified before. * objects.el: * objects.el (make-font-specifier): * objects.el (make-color-specifier): * objects.el (make-face-boolean-specifier): New. specifier doc updates according to the conventions specified before. * specifier.el: * specifier.el (set-specifier): * specifier.el (make-integer-specifier): New. * specifier.el (make-boolean-specifier): New. * specifier.el (make-natnum-specifier): New. * specifier.el (make-generic-specifier): New. * specifier.el (make-display-table-specifier): New. specifier doc updates according to the conventions specified before. * toolbar.el: * toolbar.el (make-toolbar-specifier): New. specifier doc updates according to the conventions specified before. 2000-05-09 Ben Wing <ben(a)xemacs.org&gt; lwlib/ChangeLog: man/ChangeLog: nt/ChangeLog: src/ChangeLog: ＠＠ -1,3 1,116 ＠＠ 2000-05-09 Ben Wing <ben(a)xemacs.org&gt; * buffer.c (complex_vars_of_buffer): update modeline-format doc. * device.h: comment about how DFW_DEVICE should be merged with DOMAIN_DEVICE. * emacs.c: timeline of all released versions of Emacs, for use in creating authorship comments and in synching up. * glyphs-widget.c (image_instantiator_buttons): * glyphs-widget.c (image_instantiator_edit_fields): * glyphs-widget.c (image_instantiator_combo_box): * glyphs-widget.c (image_instantiator_scrollbar): * glyphs-widget.c (image_instantiator_progress_guage): * glyphs-widget.c (image_instantiator_tree_view): * glyphs-widget.c (image_instantiator_tab_control): * glyphs-widget.c (image_instantiator_labels): * glyphs-widget.c (image_instantiator_layout): * glyphs-widget.c (image_instantiator_native_layout): rename decode_domain method to governing_domain. * glyphs.c: * glyphs.c (Fvalid_image_instantiator_format_p): doc update. * glyphs.c (add_entry_to_device_ii_format_list): make sure we don't put an entry more than once into the list. * glyphs.c (check_instance_cache_mapper): ************************************************************* allow for nil. THIS SHOULD FIX A REAL CRASH THAT MANY PEOPLE HAVE BEEN GETTING. ************************************************************* * glyphs.c (get_image_instantiator_governing_domain): clean up, expand on new concept of governing domain. * glyphs.c (instantiate_image_instantiator): * glyphs.c (allocate_image_instance): use governing_domain instead of cache_domain in naming. * glyphs.c (Fvalid_image_instance_type_p): fix docs. * glyphs.c (make_image_instance_1): * glyphs.c (Fmake_image_instance): allow for any domain (not just device), and process the governing domain correctly. very big doc fix. * glyphs.c (Fimage_instance_domain): new primitive, to retrieve the governing domain of an image instance. * glyphs.c (image_instantiate): use new governing_domain stuff. this fixes a crash you could get by instantiating certain widget glyphs in frame locales. (should signal an error instead of crashing.) * glyphs.c (Fimage_specifier_p): move doc to make-image-specifier. * glyphs.c (Fglyphp): clean up doc. * glyphs.c (subwindow_governing_domain): renamed from *_decode_domain. * glyphs.c (syms_of_glyphs): declare Fimage_instance_domain, remove unused Qlayout_image_instance_p. * glyphs.c (image_instantiator_format_create): add some comments about bogus code. * glyphs.c (specifier_vars_of_glyphs): totally rewrite the doc string for current-display-table. (Apparently Hrjove implemented in 1998 a design I wrote up in 1996, but didn't update the doc string.) * glyphs.h: clean up a doc string. * glyphs.h (governing_domain): * glyphs.h (struct image_instantiator_methods): changes for governing_domain stuff. * gutter.c: * gutter.c (Fgutter_specifier_p): * gutter.c (Fgutter_size_specifier_p): * gutter.c (Fgutter_visible_specifier_p): * objects.c: * objects.c (Fcolor_specifier_p): * objects.c (Ffont_specifier_p): * objects.c (Fface_boolean_specifier_p): doc strings moved to make-*-specifier. * redisplay.c (add_disp_table_entry_runes_1): * redisplay.c (generate_fstring_runes): * redisplay.c (screen): add random comments and doc strings. * specifier.c: * specifier.c (Fmake_specifier): major overhaul of this doc string. * specifier.c (Fvalid_specifier_domain_p): comment about the bogosity of image instances being domains. * specifier.c (decode_domain): now non-static, used in glyphs.c. * specifier.c (specifier_instance): comment about the bogosity of image instances being domains. * specifier.c (Fgeneric_specifier_p): move doc string to make-generic-specifier. * specifier.c (VALID_SINGLE_DISPTABLE_INSTANTIATOR_P): rebackslashify. * specifier.h: * specifier.h (DOMAIN_FRAME): * specifier.h (DOMAIN_LIVE_P): * specifier.h (DOMAIN_XDEVICE): rebackslashify. add comments about problems with these macros. prototype for decode_domain. * toolbar.c: * toolbar.c (Ftoolbar_specifier_p): move doc string to `make-toolbar-specifier'. * window.c (window_unmap_subwindows_cache_mapper): ************************************************************* allow for nil. THIS SHOULD FIX A REAL CRASH THAT MANY PEOPLE HAVE BEEN GETTING. ************************************************************* tests/ChangeLog: Index: lisp/faces.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/faces.el,v retrieving revision 1.18.2.15 diff -u -w -r1.18.2.15 faces.el --- faces.el 2000/04/04 09:58:31 1.18.2.15 +++ faces.el 2000/05/09 11:52:24 ＠＠ -292,41 +292,41 ＠＠ The following symbols have predefined meanings: foreground The foreground color of the face. - For valid instantiators, see `color-specifier-p'. + For valid instantiators, see `make-color-specifier'. background The background color of the face. - For valid instantiators, see `color-specifier-p'. + For valid instantiators, see `make-color-specifier'. font The font used to display text covered by this face. - For valid instantiators, see `font-specifier-p'. + For valid instantiators, see `make-font-specifier'. display-table The display table of the face. This should be a vector of 256 elements. background-pixmap The pixmap displayed in the background of the face. Only used by faces on X devices. - For valid instantiators, see `image-specifier-p'. + For valid instantiators, see `make-image-specifier'. underline Underline all text covered by this face. - For valid instantiators, see `face-boolean-specifier-p'. + For valid instantiators, see `make-face-boolean-specifier'. strikethru Draw a line through all text covered by this face. - For valid instantiators, see `face-boolean-specifier-p'. + For valid instantiators, see `make-face-boolean-specifier'. highlight Highlight all text covered by this face. Only used by faces on TTY devices. - For valid instantiators, see `face-boolean-specifier-p'. + For valid instantiators, see `make-face-boolean-specifier'. dim Dim all text covered by this face. - For valid instantiators, see `face-boolean-specifier-p'. + For valid instantiators, see `make-face-boolean-specifier'. blinking Blink all text covered by this face. Only used by faces on TTY devices. - For valid instantiators, see `face-boolean-specifier-p'. + For valid instantiators, see `make-face-boolean-specifier'. reverse Reverse the foreground and background colors. Only used by faces on TTY devices. - For valid instantiators, see `face-boolean-specifier-p'. + For valid instantiators, see `make-face-boolean-specifier'. doc-string Description of what the face's normal use is. NOTE: This is not a specifier, unlike all ＠＠ -433,7 +433,7 ＠＠ FACE may be either a face object or a symbol representing a face. -FONT should be an instantiator (see `font-specifier-p'), a list of +FONT should be an instantiator (see `make-font-specifier'), a list of instantiators, an alist of specifications (each mapping a locale to an instantiator list), or a font specifier object. ＠＠ -490,7 +490,7 ＠＠ FACE may be either a face object or a symbol representing a face. -COLOR should be an instantiator (see `color-specifier-p'), a list of +COLOR should be an instantiator (see `make-color-specifier'), a list of instantiators, an alist of specifications (each mapping a locale to an instantiator list), or a color specifier object. ＠＠ -547,7 +547,7 ＠＠ FACE may be either a face object or a symbol representing a face. -COLOR should be an instantiator (see `color-specifier-p'), a list of +COLOR should be an instantiator (see `make-color-specifier'), a list of instantiators, an alist of specifications (each mapping a locale to an instantiator list), or a color specifier object. ＠＠ -595,7 +595,7 ＠＠ FACE may be either a face object or a symbol representing a face. -PIXMAP should be an instantiator (see `image-specifier-p'), a list +PIXMAP should be an instantiator (see `make-image-specifier'), a list of instantiators, an alist of specifications (each mapping a locale to an instantiator list), or an image specifier object. ＠＠ -652,7 +652,7 ＠＠ how-to-add) "Change the underline property of FACE to UNDERLINE-P. UNDERLINE-P is normally a face-boolean instantiator; see - `face-boolean-specifier-p'. + `make-face-boolean-specifier'. See `set-face-property' for the semantics of the LOCALE, TAG-SET, and HOW-TO-ADD arguments." (interactive (face-interactive "underline-p" "underlined")) ＠＠ -667,7 +667,7 ＠＠ how-to-add) "Change whether FACE is strikethru-d (i.e. struck through) in LOCALE. STRIKETHRU-P is normally a face-boolean instantiator; see - `face-boolean-specifier-p'. + `make-face-boolean-specifier'. See `set-face-property' for the semantics of the LOCALE, TAG-SET, and HOW-TO-ADD arguments." (interactive (face-interactive "strikethru-p" "strikethru-d")) ＠＠ -682,7 +682,7 ＠＠ how-to-add) "Change whether FACE is highlighted in LOCALE (TTY locales only). HIGHLIGHT-P is normally a face-boolean instantiator; see - `face-boolean-specifier-p'. + `make-face-boolean-specifier'. See `set-face-property' for the semantics of the LOCALE, TAG-SET, and HOW-TO-ADD arguments." (interactive (face-interactive "highlight-p" "highlighted")) ＠＠ -696,7 +696,7 ＠＠ (defun set-face-dim-p (face dim-p &optional locale tag-set how-to-add) "Change whether FACE is dimmed in LOCALE. DIM-P is normally a face-boolean instantiator; see - `face-boolean-specifier-p'. + `make-face-boolean-specifier'. See `set-face-property' for the semantics of the LOCALE, TAG-SET, and HOW-TO-ADD arguments." (interactive (face-interactive "dim-p" "dimmed")) ＠＠ -711,7 +711,7 ＠＠ how-to-add) "Change whether FACE is blinking in LOCALE (TTY locales only). BLINKING-P is normally a face-boolean instantiator; see - `face-boolean-specifier-p'. + `make-face-boolean-specifier'. See `set-face-property' for the semantics of the LOCALE, TAG-SET, and HOW-TO-ADD arguments." (interactive (face-interactive "blinking-p" "blinking")) ＠＠ -725,7 +725,7 ＠＠ (defun set-face-reverse-p (face reverse-p &optional locale tag-set how-to-add) "Change whether FACE is reversed in LOCALE (TTY locales only). REVERSE-P is normally a face-boolean instantiator; see - `face-boolean-specifier-p'. + `make-face-boolean-specifier'. See `set-face-property' for the semantics of the LOCALE, TAG-SET, and HOW-TO-ADD arguments." (interactive (face-interactive "reverse-p" "reversed")) Index: lisp/glyphs.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/glyphs.el,v retrieving revision 1.6.2.1 diff -u -w -r1.6.2.1 glyphs.el --- glyphs.el 1998/12/18 05:41:59 1.6.2.1 +++ glyphs.el 2000/05/09 11:52:26 ＠＠ -1,7 +1,7 ＠＠ ;;; glyphs.el --- Lisp interface to C glyphs ;; Copyright (C) 1994, 1997 Free Software Foundation, Inc. -;; Copyright (C) 1995, 1996 Ben Wing. +;; Copyright (C) 1995, 1996, 2000 Ben Wing. ;; Author: Chuck Thompson <cthomp(a)cs.uiuc.edu&gt;, Ben Wing <ben(a)xemacs.org&gt; ;; Maintainer: XEmacs Development Team ＠＠ -26,27 +26,287 ＠＠ ;;; 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: -;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; font specifiers +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; image 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." +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). +" (make-specifier-and-init 'image spec-list)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; glyphs (defconst built-in-glyph-specifiers '(image contrib-p baseline) - "A list of the built-in face properties that are specifiers.") + "A list of the built-in glyph properties that are specifiers.") (defun glyph-property (glyph property &optional locale) "Return GLYPH's value of PROPERTY in LOCALE. ＠＠ -287,7 +547,7 ＠＠ "Change the image of GLYPH in LOCALE. SPEC should be an instantiator (a string or vector; see - `image-specifier-p' for a description of possible values here), + `make-image-specifier' 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. ＠＠ -380,20 +640,162 ＠＠ (set-glyph-property glyph 'baseline spec locale tag-set how-to-add)) (defun make-glyph (&optional spec-list type) - "Return a new `glyph' object of type TYPE. + "Create a new glyph of type TYPE. -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'. +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'. + +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.) + +-- 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. -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." +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'." (let ((glyph (make-glyph-internal type))) (and spec-list (set-glyph-image glyph spec-list)) glyph)) ＠＠ -412,38 +814,22 ＠＠ (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'. - -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. +See `make-glyph' for more information. -You can also create a glyph with an empty SPEC-LIST and add image -instantiators afterwards using `set-glyph-image'." +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'." (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. -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'." +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'." (make-glyph spec-list 'icon)) (defun nothing-image-instance-p (object) ＠＠ -468,9 +854,12 ＠＠ "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'. -Subwindows are not implemented in this version of XEmacs." + "Return t if OBJECT is an image instance of type `subwindow'." (and (image-instance-p object) (eq 'subwindow (image-instance-type object)))) ;;;;;;;;;; the built-in glyphs Index: lisp/gutter.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/Attic/gutter.el,v retrieving revision 1.1.2.1 diff -u -w -r1.1.2.1 gutter.el --- gutter.el 2000/04/14 16:15:33 1.1.2.1 +++ gutter.el 2000/05/09 11:52:26 ＠＠ -108,6 +108,61 ＠＠ (or (and (listp spec) (memq 'buffers-tab spec)) spec))) +(defun make-gutter-specifier (spec-list) + "Return a new `gutter' specifier object with the given specification 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. + +Gutter specifiers are used to specify the format of a gutter. +The values of the variables `default-gutter', `top-gutter', +`left-gutter', `right-gutter', and `bottom-gutter' are always +gutter specifiers. + +Valid gutter instantiators are called \"gutter descriptors\" and are +either strings or property-lists of strings. See `default-gutter' for +a description of the exact format." + (make-specifier-and-init 'gutter spec-list)) + +(defun make-gutter-size-specifier (spec-list) + "Return a new `gutter-size' specifier object with the given 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. + +Gutter-size specifiers are used to specify the size of a gutter. The +values of the variables `default-gutter-size', `top-gutter-size', +`left-gutter-size', `right-gutter-size', and `bottom-gutter-size' are +always gutter-size specifiers. + +Valid gutter-size instantiators are either integers or the special +symbol 'autodetect. If a gutter-size is set to 'autodetect them the +size of the gutter will be adjusted to just accomodate the gutters +contents. 'autodetect only works for top and bottom gutters." + (make-specifier-and-init 'gutter-size spec-list)) + +(defun make-gutter-visible-specifier (spec-list) + "Return a new `gutter-visible' specifier object with the given 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. + +Gutter-visible specifiers are used to specify the visibility of a +gutter. The values of the variables `default-gutter-visible-p', +`top-gutter-visible-p', `left-gutter-visible-p', +`right-gutter-visible-p', and `bottom-gutter-visible-p' are always +gutter-visible specifiers. + +Valid gutter-visible instantiators are t, nil or a list of symbols. +If a gutter-visible instantiator is set to a list of symbols, and the +correspondong gutter specification is a property-list strings, then +elements of the gutter specification will only be visible if the +corresponding symbol occurs in the gutter-visible instantiator." + (make-specifier-and-init 'gutter-visible spec-list)) + (defun init-gutter () "Initialize the gutter." ;; do nothing as yet. Index: lisp/objects.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/objects.el,v retrieving revision 1.4 diff -u -w -r1.4 objects.el --- objects.el 1998/06/30 06:35:25 1.4 +++ objects.el 2000/05/09 11:52:26 ＠＠ -46,7 +46,19 ＠＠ 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." +specifiers. + +Valid instantiators for font specifiers are: + +-- a string naming a font (e.g. under X this might be + \"-*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-*\" for a 14-point + upright medium-weight Courier font) +-- a font instance (use that instance directly if the device matches, + or use the string that generated it) +-- a vector of no elements (only on TTY's; this means to set no font + at all, thus using the \"natural\" font of the terminal's text) +-- a vector of one element (a face to inherit from) +" (make-specifier-and-init 'font spec-list)) (defun font-name (font &optional domain charset) ＠＠ -127,7 +139,21 ＠＠ 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 a detailed description of -how specifiers work." +how specifiers work. + +Valid instantiators for color specifiers are: + +-- a string naming a color (e.g. under X this might be \"lightseagreen2\" + or \"#F534B2\") +-- a color instance (use that instance directly if the device matches, + or use the string that generated it) +-- a vector of no elements (only on TTY's; this means to set no color + at all, thus using the \"natural\" color of the terminal's text) +-- a vector of one or two elements: a face to inherit from, and + optionally a symbol naming which property of that face to inherit, + either `foreground' or `background' (if omitted, defaults to the same + property that this color specifier is used for; if this specifier is + not part of a face, the instantiator would not be valid)." (make-specifier-and-init 'color spec-list)) (defun color-name (color &optional domain) ＠＠ -145,5 +171,25 ＠＠ to using `specifier-instance' and applying `color-instance-rgb-components' to the result. See `make-specifier' for more information about specifiers." (ws-object-property-1 'color-instance-rgb-components color domain)) + +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; face-boolean specifiers + +(defun make-face-boolean-specifier (spec-list) + "Return a new `face-boolean' specifier object with the given 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 a detailed description of +how specifiers work. + +Valid instantiators for face-boolean specifiers are + +-- t or nil +-- a vector of two or three elements: a face to inherit from, + optionally a symbol naming the property of that face to inherit from + (if omitted, defaults to the same property that this face-boolean + specifier is used for; if this specifier is not part of a face, + the instantiator would not be valid), and optionally a value which, + if non-nil, means to invert the sense of the inherited property." + (make-specifier-and-init 'color spec-list)) ;;; objects.el ends here. Index: lisp/specifier.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/specifier.el,v retrieving revision 1.8.2.1 diff -u -w -r1.8.2.1 specifier.el --- specifier.el 2000/02/27 21:22:57 1.8.2.1 +++ specifier.el 2000/05/09 11:52:26 ＠＠ -1,7 +1,7 ＠＠ ;;; specifier.el --- Lisp interface to specifiers ;; Copyright (C) 1997 Free Software Foundation, Inc. -;; Copyright (C) 1995, 1996 Ben Wing. +;; Copyright (C) 1995, 1996, 2000 Ben Wing. ;; Author: Ben Wing <ben(a)xemacs.org&gt; ;; Keywords: internal, dumped ＠＠ -275,18 +275,20 ＠＠ VALUE is usually what is called an \"instantiator\" (which, roughly speaking, corresponds to the \"value\" of the property governed by -SPECIFIER). The valid instantiators for SPECIFIER depend on the -type of SPECIFIER (which you can determine using `specifier-type'). -The specifier `scrollbar-width', for example, is of type `integer', -meaning its valid instantiators are integers. The specifier -governing the background color of the `default' face (you can -retrieve this specifier using `(face-background 'default)') is -of type `color', meaning its valid instantiators are strings naming -colors and color-instance objects. For some types of specifiers, -such as `image' and `toolbar', the instantiators can be very -complex. Generally this is documented in the appropriate predicate -function -- `color-specifier-p', `image-specifier-p', -`toolbar-specifier-p', etc. +SPECIFIER). The valid instantiators for SPECIFIER depend on the type +of SPECIFIER (which you can determine using `specifier-type'). The +specifier `scrollbar-width', for example, is of type `integer', +meaning its valid instantiators are integers. The specifier governing +the background color of the `default' face (you can retrieve this +specifier using `(face-background 'default)') is of type `color', +meaning its valid instantiators are strings naming colors and +color-instance objects. For some types of specifiers, such as `image' +and `toolbar', the instantiators can be very complex. Generally this +is documented in the appropriate creation function -- +e.g. `make-color-specifier', `make-font-specifier', +`make-image-specifier' -- or in the global variable holding the most +common specifier for that type (`default-toolbar', `default-gutter', +`current-display-table'). NOTE: It does *not* work to give a VALUE of nil as a way of removing the specifications for a locale. Use `remove-specifier' ＠＠ -525,6 +527,58 ＠＠ ,(car (nth 0 varel)) ,(car oldval)))) oldvallist varlist)))))))) + +(defun make-integer-specifier (spec-list) + "Return a new `integer' specifier object with the given specification 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. + +Valid instantiators for integer specifiers are integers." + (make-specifier-and-init 'integer spec-list)) + +(defun make-boolean-specifier (spec-list) + "Return a new `boolean' specifier object with the given specification 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. + +Valid instantiators for boolean specifiers are t and nil." + (make-specifier-and-init 'boolean spec-list)) + +(defun make-natnum-specifier (spec-list) + "Return a new `natnum' specifier object with the given specification 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. + +Valid instantiators for natnum specifiers are non-negative integers." + (make-specifier-and-init 'natnum spec-list)) + +(defun make-generic-specifier (spec-list) + "Return a new `generic' specifier object with the given specification 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. + +Valid instantiators for generic specifiers are all Lisp values. +They are returned back unchanged when a specifier is instantiated." + (make-specifier-and-init 'generic spec-list)) + +(defun make-display-table-specifier (spec-list) + "Return a new `display-table' specifier object with the given 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. + +Valid instantiators for display-table specifiers are described in +detail in the doc string for `current-display-table'." + (make-specifier-and-init 'display-table spec-list)) ;; Evaluate this for testing: ; (cl-prettyexpand '(let-specifier ((modeline-shadow-thickness 0 (selected-window) 'x) (fubar (value) baz)) (sit-for 1))) Index: lisp/toolbar.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/toolbar.el,v retrieving revision 1.8.2.3 diff -u -w -r1.8.2.3 toolbar.el --- toolbar.el 2000/02/07 20:53:54 1.8.2.3 +++ toolbar.el 2000/05/09 11:52:26 ＠＠ -198,4 +198,21 ＠＠ (setq zmacs-region-stays t) (release-toolbar-button-internal event nil)) +(defun make-toolbar-specifier (spec-list) + "Return a new `toolbar' specifier object with the given specification 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. + +Toolbar specifiers are used to specify the format of a toolbar. +The values of the variables `default-toolbar', `top-toolbar', +`left-toolbar', `right-toolbar', and `bottom-toolbar' are always +toolbar specifiers. + +Valid toolbar instantiators are called \"toolbar descriptors\" +and are lists of vectors. See `default-toolbar' for a description +of the exact format." + (make-specifier-and-init 'toolbar spec-list)) + ;;; toolbar.el ends here Index: src/buffer.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/buffer.c,v retrieving revision 1.36.2.29 diff -u -w -r1.36.2.29 buffer.c --- buffer.c 2000/04/28 09:25:21 1.36.2.29 +++ buffer.c 2000/05/09 11:52:35 ＠＠ -2661,11 +2661,14 ＠＠ DEFVAR_BUFFER_LOCAL ("modeline-format", modeline_format /* Template for displaying modeline for current buffer. Each buffer has its own value of this variable. -Value may be a string, a symbol or a list or cons cell. -For a symbol, its value is used (but it is ignored if t or nil). +Value may be a string, symbol, glyph, generic specifier, list or cons cell. +For a symbol, its value is processed (but it is ignored if t or nil). A string appearing directly as the value of a symbol is processed verbatim in that the %-constructs below are not recognized. For a glyph, it is inserted as is. +For a generic specifier (i.e. a specifier of type `generic'), its instance + is computed in the current window using the equivalent of `specifier-instance' + and the value is processed. For a list whose car is a symbol, the symbol's value is taken, and if that is non-nil, the cadr of the list is processed recursively. Otherwise, the caddr of the list (if there is one) is processed. ＠＠ -2679,13 +2682,10 ＠＠ extent, and mouse clicks over this section are processed using the keymap of the extent. (In addition, if the extent has a help-echo property, that string will be echoed when the mouse moves over this - section.) See `generated-modeline-string' for more information. -For a list whose car is a face, the cdr of the list is processed - normally but the results will be displayed using the face in the car. -For a list whose car is a keymap, the cdr of the list is processed - normally but the keymap will apply for mouse clicks over the results, - in addition to `modeline-map'. Nested keymap specifications are - handled properly. + section.) If extents are nested, all keymaps are properly consulted + when processing mouse clicks, but multiple faces are not correctly + merged (only the first face is used), and lists of faces are not + correctly handled. See `generated-modeline-string' for more information. A string is printed verbatim in the modeline except for %-constructs: (%-constructs are processed when the string is the entire modeline-format or when it is found in a cons-cell or a list) Index: src/device.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device.h,v retrieving revision 1.8.2.9 diff -u -w -r1.8.2.9 device.h --- device.h 2000/02/26 11:39:46 1.8.2.9 +++ device.h 2000/05/09 11:52:35 ＠＠ -426,6 +426,8 ＠＠ #define MARK_DEVICE_WINDOWS_STRUCTURE_CHANGED(d) \ ((void) (windows_structure_changed = (d)->windows_structure_changed = 1)) +/* #### unify this with DOMAIN_DEVICE once the latter has image instances + expunged from it. */ /* This turns out to be used heavily so we make it a macro to make it inline. Also, the majority of the time the object will turn out to be a window so we move it from being checked last to being checked Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.61 diff -u -w -r1.82.2.61 emacs.c --- emacs.c 2000/04/28 03:50:32 1.82.2.61 +++ emacs.c 2000/05/09 11:52:38 ＠＠ -22,6 +22,141 ＠＠ /* Synched up with: Mule 2.0, FSF 19.28. */ +/* Capsule summary of the various releases of Lucid Emacs/XEmacs and + FSF/GNU Emacs. Provided here for use in cross-referencing version + releases and dates in comments, esp. in the authorship comments at + the beginning of each file. More information about history can be + found in the beginning of the Internals Manual and in the About page. + + +-- A time line for Lucid Emacs/XEmacs is + +version 19.0 shipped with Energize 1.0, April 1992. +version 19.1 released June 4, 1992. +version 19.2 released June 19, 1992. +version 19.3 released September 9, 1992. +version 19.4 released January 21, 1993. +version 19.5 was a repackaging of 19.4 with a few bug fixes and + shipped with Energize 2.0. Never released to the net. +version 19.6 released April 9, 1993. +version 19.7 was a repackaging of 19.6 with a few bug fixes and + shipped with Energize 2.1. Never released to the net. +version 19.8 released September 6, 1993. +version 19.9 released January 12, 1994. +version 19.10 released May 27, 1994. +version 19.11 (first XEmacs) released September 13, 1994. +version 19.12 released June 23, 1995. +version 19.13 released September 1, 1995. +version 19.14 released June 23, 1996. +version 20.0 released February 9, 1997. +version 19.15 released March 28, 1997. +version 20.1 (not released to the net) April 15, 1997. +version 20.2 released May 16, 1997. +version 19.16 released October 31, 1997. +version 20.3 (the first stable version of XEmacs 20.x) released + November 30, 1997. +version 20.4 released February 28, 1998. + + +-- A time line for GNU Emacs version 19 is + +version 19.7 (beta) (first beta release) released ??????; prob. late May 1993. +version 19.8 (beta) released May 27, 1993. +version 19.9 (beta) released May 27, 1993. +version 19.10 (beta) released May 30, 1993. +version 19.11 (beta) released June 1, 1993. +version 19.12 (beta) released June 2, 1993. +version 19.13 (beta) released June 8, 1993. +version 19.14 (beta) released June 17, 1993. +version 19.15 (beta) released June 19, 1993. +version 19.16 (beta) released July 6, 1993. +version 19.17 (beta) released late July, 1993. +version 19.18 (beta) released August 9, 1993. +version 19.19 (beta) released August 15, 1993. +version 19.20 (beta) released November 17, 1993. +version 19.21 (beta) released November 17, 1993. +version 19.22 (beta) released November 28, 1993. +version 19.23 (beta) released May 17, 1994. +version 19.24 (beta) released May 16, 1994. +version 19.25 (beta) released June 3, 1994. +version 19.26 (beta) released September 11, 1994. +version 19.27 (beta) released September 14, 1994. +version 19.28 (first ``official'' release) released November 1, 1994. +version 19.29 released June 21, 1995. +version 19.30 released November 24, 1995. +version 19.31 released May 25, 1996. +version 19.32 released July 31, 1996. +version 19.33 released August 11, 1996. +version 19.34 released August 21, 1996. +version 19.34b released September 6, 1996. + + +-- A time line for GNU Emacs version 20 is + +version 20.1 released September 17, 1997. +version 20.2 released September 20, 1997. +version 20.3 released August 19, 1998. + + +-- A time line for GNU Emacs version 18 and older is + +GNU Emacs version 15 (15.34) was released sometime in 1984 or 1985 and + shared some code with a version of Emacs written by James Gosling (the + same James Gosling who later created the Java language). +GNU Emacs version 16 (first released version was 16.56) was released on + July 15, 1985. All Gosling code was removed due to potential copyright + problems with the code. +version 16.57: released on September 16, 1985. +versions 16.58, 16.59: released on September 17, 1985. +version 16.60: released on September 19, 1985. These later version 16's + incorporated patches from the net, esp. for getting Emacs to work under + System V. +version 17.36 (first official v17 release) released on December 20, 1985. + Included a TeX-able user manual. First official unpatched version that + worked on vanilla System V machines. +version 17.43 (second official v17 release) released on January 25, 1986. +version 17.45 released on January 30, 1986. +version 17.46 released on February 4, 1986. +version 17.48 released on February 10, 1986. +version 17.49 released on February 12, 1986. +version 17.55 released on March 18, 1986. +version 17.57 released on March 27, 1986. +version 17.58 released on April 4, 1986. +version 17.61 released on April 12, 1986. +version 17.63 released on May 7, 1986. +version 17.64 released on May 12, 1986. +version 18.24 (a beta version) released on October 2, 1986. +version 18.30 (a beta version) released on November 15, 1986. +version 18.31 (a beta version) released on November 23, 1986. +version 18.32 (a beta version) released on December 7, 1986. +version 18.33 (a beta version) released on December 12, 1986. +version 18.35 (a beta version) released on January 5, 1987. +version 18.36 (a beta version) released on January 21, 1987. +January 27, 1987: The Great Usenet Renaming. net.emacs is now comp.emacs. +version 18.37 (a beta version) released on February 12, 1987. +version 18.38 (a beta version) released on March 3, 1987. +version 18.39 (a beta version) released on March 14, 1987. +version 18.40 (a beta version) released on March 18, 1987. +version 18.41 (the first ``official'' release) released on March 22, 1987. +version 18.45 released on June 2, 1987. +version 18.46 released on June 9, 1987. +version 18.47 released on June 18, 1987. +version 18.48 released on September 3, 1987. +version 18.49 released on September 18, 1987. +version 18.50 released on February 13, 1988. +version 18.51 released on May 7, 1988. +version 18.52 released on September 1, 1988. +version 18.53 released on February 24, 1989. +version 18.54 released on April 26, 1989. +version 18.55 released on August 23, 1989. This is the earliest version + that is still available by FTP. +version 18.56 released on January 17, 1991. +version 18.57 released late January, 1991. +version 18.58 released ?????. +version 18.59 released October 31, 1992. + +*/ + /* Note: It is necessary to specify <config.h> and not "config.h" in order for the --srcdir type of compilation to work properly. Otherwise the config.h from the srcdir, rather than the one from Index: src/glyphs-widget.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/Attic/glyphs-widget.c,v retrieving revision 1.1.2.40 diff -u -w -r1.1.2.40 glyphs-widget.c --- glyphs-widget.c 2000/05/03 14:47:06 1.1.2.40 +++ glyphs-widget.c 2000/05/09 11:52:39 ＠＠ -1310,7 +1310,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (button, instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (button, post_instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (button, normalize, widget); - IIFORMAT_HAS_SHARED_METHOD (button, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (button, governing_domain, subwindow); IIFORMAT_HAS_METHOD (button, query_geometry); IIFORMAT_VALID_KEYWORD (button, Q_image, check_valid_glyph_or_instantiator); ＠＠ -1325,7 +1325,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (edit_field, possible_dest_types, widget); IIFORMAT_HAS_SHARED_METHOD (edit_field, instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (edit_field, post_instantiate, widget); - IIFORMAT_HAS_SHARED_METHOD (edit_field, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (edit_field, governing_domain, subwindow); VALID_WIDGET_KEYWORDS (edit_field); VALID_GUI_KEYWORDS (edit_field); } ＠＠ -1335,7 +1335,7 ＠＠ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (combo_box, "combo-box"); IIFORMAT_HAS_METHOD (combo_box, validate); IIFORMAT_HAS_SHARED_METHOD (combo_box, possible_dest_types, widget); - IIFORMAT_HAS_SHARED_METHOD (combo_box, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (combo_box, governing_domain, subwindow); VALID_GUI_KEYWORDS (combo_box); ＠＠ -1353,7 +1353,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (scrollbar, possible_dest_types, widget); IIFORMAT_HAS_SHARED_METHOD (scrollbar, instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (scrollbar, post_instantiate, widget); - IIFORMAT_HAS_SHARED_METHOD (scrollbar, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (scrollbar, governing_domain, subwindow); VALID_GUI_KEYWORDS (scrollbar); IIFORMAT_VALID_KEYWORD (scrollbar, Q_pixel_width, check_valid_int_or_function); ＠＠ -1368,7 +1368,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (progress_gauge, possible_dest_types, widget); IIFORMAT_HAS_SHARED_METHOD (progress_gauge, instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (progress_gauge, post_instantiate, widget); - IIFORMAT_HAS_SHARED_METHOD (progress_gauge, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (progress_gauge, governing_domain, subwindow); IIFORMAT_HAS_METHOD (progress_gauge, set_property); VALID_WIDGET_KEYWORDS (progress_gauge); VALID_GUI_KEYWORDS (progress_gauge); ＠＠ -1381,7 +1381,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (tree_view, possible_dest_types, widget); IIFORMAT_HAS_SHARED_METHOD (tree_view, instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (tree_view, post_instantiate, widget); - IIFORMAT_HAS_SHARED_METHOD (tree_view, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (tree_view, governing_domain, subwindow); IIFORMAT_HAS_METHOD (tree_view, query_geometry); VALID_WIDGET_KEYWORDS (tree_view); VALID_GUI_KEYWORDS (tree_view); ＠＠ -1395,7 +1395,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (tab_control, possible_dest_types, widget); IIFORMAT_HAS_SHARED_METHOD (tab_control, instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (tab_control, post_instantiate, widget); - IIFORMAT_HAS_SHARED_METHOD (tab_control, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (tab_control, governing_domain, subwindow); IIFORMAT_HAS_METHOD (tab_control, query_geometry); IIFORMAT_HAS_METHOD (tab_control, set_property); VALID_WIDGET_KEYWORDS (tab_control); ＠＠ -1410,7 +1410,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (label, possible_dest_types, widget); IIFORMAT_HAS_SHARED_METHOD (label, instantiate, widget); IIFORMAT_HAS_SHARED_METHOD (label, post_instantiate, widget); - IIFORMAT_HAS_SHARED_METHOD (label, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (label, governing_domain, subwindow); VALID_WIDGET_KEYWORDS (label); IIFORMAT_VALID_KEYWORD (label, Q_descriptor, check_valid_string); } ＠＠ -1430,7 +1430,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (layout, possible_dest_types, widget); IIFORMAT_HAS_METHOD (layout, instantiate); IIFORMAT_HAS_METHOD (layout, post_instantiate); - IIFORMAT_HAS_SHARED_METHOD (layout, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (layout, governing_domain, subwindow); IIFORMAT_HAS_METHOD (layout, normalize); IIFORMAT_HAS_METHOD (layout, query_geometry); IIFORMAT_HAS_METHOD (layout, layout); ＠＠ -1446,7 +1446,7 ＠＠ IIFORMAT_HAS_SHARED_METHOD (native_layout, instantiate, layout); IIFORMAT_HAS_SHARED_METHOD (native_layout, post_instantiate, layout); IIFORMAT_HAS_METHOD (native_layout, layout); - IIFORMAT_HAS_SHARED_METHOD (native_layout, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (native_layout, governing_domain, subwindow); IIFORMAT_HAS_SHARED_METHOD (native_layout, normalize, layout); IIFORMAT_HAS_SHARED_METHOD (native_layout, query_geometry, layout); IIFORMAT_HAS_SHARED_METHOD (native_layout, layout, layout); Index: src/glyphs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.c,v retrieving revision 1.23.2.66 diff -u -w -r1.23.2.66 glyphs.c --- glyphs.c 2000/05/09 11:26:49 1.23.2.66 +++ glyphs.c 2000/05/09 11:52:40 ＠＠ -1,7 +1,7 ＠＠ /* Generic glyph/image implementation + display tables Copyright (C) 1994, 1995 Board of Trustees, University of Illinois. Copyright (C) 1995 Tinker Systems - Copyright (C) 1995, 1996 Ben Wing + Copyright (C) 1995, 1996, 2000 Ben Wing Copyright (C) 1995 Sun Microsystems Copyright (C) 1998, 1999, 2000 Andy Piper ＠＠ -30,21 +30,21 ＠＠ #include <config.h> #include "lisp.h" +#include "blocktype.h" #include "buffer.h" +#include "chartab.h" #include "device.h" #include "elhash.h" #include "faces.h" #include "frame.h" +#include "glyphs.h" #include "insdel.h" -#include "opaque.h" #include "objects.h" +#include "opaque.h" +#include "rangetab.h" #include "redisplay.h" +#include "specifier.h" #include "window.h" -#include "frame.h" -#include "chartab.h" -#include "rangetab.h" -#include "blocktype.h" -#include "glyphs.h" #ifdef HAVE_XPM #include <X11/xpm.h> ＠＠ -59,7 +59,6 ＠＠ Lisp_Object Qcolor_pixmap_image_instance_p; Lisp_Object Qpointer_image_instance_p; Lisp_Object Qsubwindow_image_instance_p; -Lisp_Object Qlayout_image_instance_p; Lisp_Object Qwidget_image_instance_p; Lisp_Object Qconst_glyph_variable; Lisp_Object Qmono_pixmap, Qcolor_pixmap, Qsubwindow; ＠＠ -122,10 +121,11 ＠＠ Dynarr_declare (struct image_instantiator_format_entry); } image_instantiator_format_entry_dynarr; +/* This contains one entry per format, per device it's defined on. */ image_instantiator_format_entry_dynarr * the_image_instantiator_format_entry_dynarr; -static Lisp_Object allocate_image_instance (Lisp_Object cache_domain, +static Lisp_Object allocate_image_instance (Lisp_Object governing_domain, Lisp_Object glyph); static void image_validate (Lisp_Object instantiator); static void glyph_property_was_changed (Lisp_Object glyph, ＠＠ -225,13 +225,18 ＠＠ Given an IMAGE-INSTANTIATOR-FORMAT, return non-nil if it is valid. If LOCALE is non-nil then the format is checked in that domain. If LOCALE is nil the current console is used. + Valid formats are some subset of 'nothing, 'string, 'formatted-string, 'xpm, 'xbm, 'xface, 'gif, 'jpeg, 'png, 'tiff, 'cursor-font, 'font, -'autodetect, 'widget and 'subwindow, depending on how XEmacs was compiled. +'autodetect, 'subwindow, 'inherit, 'mswindows-resource, 'bmp, +'native-layout, 'layout, 'label, 'tab-control, 'tree-view, +'progress-gauge, 'scrollbar, 'combo-box, 'edit-field, 'button, +'widget, 'pointer, and 'text, depending on how XEmacs was compiled. */ (image_instantiator_format, locale)) { - return valid_image_instantiator_format_p (image_instantiator_format, locale) ? + return valid_image_instantiator_format_p (image_instantiator_format, + locale) ? Qt : Qnil; } ＠＠ -254,6 +259,7 ＠＠ entry.device = device; entry.meths = meths; Dynarr_add (the_image_instantiator_format_entry_dynarr, entry); + if (NILP (memq_no_quit (symbol, Vimage_instantiator_format_list))) Vimage_instantiator_format_list = Fcons (symbol, Vimage_instantiator_format_list); } ＠＠ -551,9 +557,13 ＠＠ void *flag_closure) { /* This function can GC */ + /* value can be nil; we cache failures as well as successes */ + if (!NILP (value)) + { Lisp_Object window; VOID_TO_LISP (window, flag_closure); assert (EQ (XIMAGE_INSTANCE_DOMAIN (value), window)); + } return 0; } ＠＠ -584,17 +594,41 ＠＠ } #endif -/* Determine what domain the image instance should be cached in. */ +/* Determine what kind of domain governs the image instance. + Verify that the given domain is at least as specific, and extract + the governing domain from it. */ static Lisp_Object -decode_image_instantiator_domain (Lisp_Object instantiator, +get_image_instantiator_governing_domain (Lisp_Object instantiator, Lisp_Object domain) { - Lisp_Object device = DOMAIN_DEVICE (domain); + int governing_domain; + struct image_instantiator_methods *meths = decode_image_instantiator_format (XVECTOR_DATA (instantiator)[0], ERROR_ME); - return IIFORMAT_METH_OR_GIVEN (meths, decode_domain, (instantiator, domain), - device); + governing_domain = IIFORMAT_METH_OR_GIVEN (meths, governing_domain, (), + GOVERNING_DOMAIN_DEVICE); + + if (governing_domain == GOVERNING_DOMAIN_WINDOW + && !WINDOWP (domain)) + signal_simple_error_2 ("Domain for this instantiator must be window", + instantiator, domain); + else if (governing_domain == GOVERNING_DOMAIN_FRAME + && !(WINDOWP (domain) || FRAMEP (domain))) + signal_simple_error_2 + ("Domain for this instantiator must be window or frame", + instantiator, domain); + + if (governing_domain == GOVERNING_DOMAIN_WINDOW) + domain = DOMAIN_WINDOW (domain); + else if (governing_domain == GOVERNING_DOMAIN_FRAME) + domain = DOMAIN_FRAME (domain); + else if (governing_domain == GOVERNING_DOMAIN_DEVICE) + domain = DOMAIN_DEVICE (domain); + else + abort (); + + return domain; } static Lisp_Object ＠＠ -631,19 +665,20 ＠＠ } static Lisp_Object -instantiate_image_instantiator (Lisp_Object cache_domain, Lisp_Object domain, +instantiate_image_instantiator (Lisp_Object governing_domain, + Lisp_Object domain, Lisp_Object instantiator, Lisp_Object pointer_fg, Lisp_Object pointer_bg, int dest_mask, Lisp_Object glyph) { - Lisp_Object ii = allocate_image_instance (cache_domain, glyph); + Lisp_Object ii = allocate_image_instance (governing_domain, glyph); Lisp_Image_Instance* p = XIMAGE_INSTANCE (ii); struct image_instantiator_methods *meths, *device_meths; struct gcpro gcpro1; GCPRO1 (ii); if (!valid_image_instantiator_format_p (XVECTOR_DATA (instantiator)[0], - DOMAIN_DEVICE (cache_domain))) + DOMAIN_DEVICE (governing_domain))) signal_simple_error ("Image instantiator format is invalid in this locale.", instantiator); ＠＠ -654,7 +689,7 ＠＠ pointer_bg, dest_mask, domain)); /* Now do device specific instantiation. */ - device_meths = decode_device_ii_format (DOMAIN_DEVICE (cache_domain), + device_meths = decode_device_ii_format (DOMAIN_DEVICE (governing_domain), XVECTOR_DATA (instantiator)[0], ERROR_ME_NOT); ＠＠ -1119,7 +1154,7 ＠＠ Lisp_Image_Instance); static Lisp_Object -allocate_image_instance (Lisp_Object cache_domain, Lisp_Object glyph) +allocate_image_instance (Lisp_Object governing_domain, Lisp_Object glyph) { Lisp_Image_Instance *lp = alloc_lcrecord_type (Lisp_Image_Instance, &lrecord_image_instance); ＠＠ -1132,12 +1167,12 ＠＠ valid. However, the only truly relevant domain is the domain in which the instance is cached since this is the one that will be common to the instances. */ - lp->domain = cache_domain; + lp->domain = governing_domain; /* The cache domain is not quite sufficient since the domain can get deleted before the image instance does. We need to know the domain device in order to finalize the image instance properly. We therefore record the device also. */ - lp->device = DOMAIN_DEVICE (cache_domain); + lp->device = DOMAIN_DEVICE (governing_domain); lp->type = IMAGE_NOTHING; lp->name = Qnil; lp->x_offset = 0; ＠＠ -1264,7 +1299,7 ＠＠ DEFUN ("valid-image-instance-type-p", Fvalid_image_instance_type_p, 1, 1, 0, /* Given an IMAGE-INSTANCE-TYPE, return non-nil if it is valid. Valid types are some subset of 'nothing, 'text, 'mono-pixmap, 'color-pixmap, -'pointer, and 'subwindow, depending on how XEmacs was compiled. +'pointer, 'subwindow, and 'widget, depending on how XEmacs was compiled. */ (image_instance_type)) { ＠＠ -1315,26 +1350,32 ＠＠ } static Lisp_Object -make_image_instance_1 (Lisp_Object data, Lisp_Object device, +make_image_instance_1 (Lisp_Object data, Lisp_Object domain, Lisp_Object dest_types) { Lisp_Object ii; struct gcpro gcpro1; int dest_mask; + Lisp_Object governing_domain; - XSETDEVICE (device, decode_device (device)); - /* instantiate_image_instantiator() will abort if given an - image instance ... */ if (IMAGE_INSTANCEP (data)) signal_simple_error ("Image instances not allowed here", data); image_validate (data); + domain = decode_domain (domain); + /* instantiate_image_instantiator() will abort if given an + image instance ... */ dest_mask = decode_image_instance_type_list (dest_types); - data = normalize_image_instantiator (data, DEVICE_TYPE (XDEVICE (device)), + data = normalize_image_instantiator (data, + DEVICE_TYPE (DOMAIN_XDEVICE (domain)), make_int (dest_mask)); GCPRO1 (data); - if (VECTORP (data) && EQ (XVECTOR_DATA (data)[0], Qinherit)) + /* After normalizing the data, it's always either an image instance (which + we filtered out above) or a vector. */ + if (EQ (XVECTOR_DATA (data)[0], Qinherit)) signal_simple_error ("Inheritance not allowed here", data); - ii = instantiate_image_instantiator (device, device, data, + governing_domain = + get_image_instantiator_governing_domain (XVECTOR_DATA (data)[0], domain); + ii = instantiate_image_instantiator (governing_domain, domain, data, Qnil, Qnil, dest_mask, Qnil); RETURN_UNGCPRO (ii); } ＠＠ -1349,7 +1390,7 ＠＠ instances, if you want more control over the instantiation process. DATA is an image instantiator, which describes the image; see -`image-specifier-p' for a description of the allowed values. +`make-image-specifier' for a description of the allowed values. DEST-TYPES should be a list of allowed image instance types that can be generated. The recognized image instance types are ＠＠ -1376,37 +1417,69 ＠＠ another program to be responsible for drawing into the window. 'widget A child window that contains a window-system widget, e.g. a push - button. + button, text field, or slider. -The DEST-TYPES list is unordered. If multiple destination types -are possible for a given instantiator, the "most natural" type -for the instantiator's format is chosen. (For XBM, the most natural -types are `mono-pixmap', followed by `color-pixmap', followed by -`pointer'. For the other normal image formats, the most natural -types are `color-pixmap', followed by `mono-pixmap', followed by -`pointer'. For the string and formatted-string formats, the most -natural types are `text', followed by `mono-pixmap' (not currently -implemented), followed by `color-pixmap' (not currently implemented). -The other formats can only be instantiated as one type. (If you -want to control more specifically the order of the types into which -an image is instantiated, just call `make-image-instance' repeatedly -until it succeeds, passing less and less preferred destination types -each time. +The DEST-TYPES list is unordered. If multiple destination types are +possible for a given instantiator, the "most natural" type for the +instantiator's format is chosen. (For XBM, the most natural types are +`mono-pixmap', followed by `color-pixmap', followed by `pointer'. For +the other normal image formats, the most natural types are +`color-pixmap', followed by `mono-pixmap', followed by `pointer'. For +the string and formatted-string formats, the most natural types are +`text', followed by `mono-pixmap' (not currently implemented), +followed by `color-pixmap' (not currently implemented). For MS +Windows resources, the most natural type for pointer resources is +`pointer', and for the others it's `color-pixmap'. The other formats +can only be instantiated as one type. (If you want to control more +specifically the order of the types into which an image is +instantiated, just call `make-image-instance' repeatedly until it +succeeds, passing less and less preferred destination types each +time.) +See `make-image-specifier' for a description of the different image +instantiator formats. + If DEST-TYPES is omitted, all possible types are allowed. +DOMAIN specifies the domain to which the image instance will be attached. +This domain is termed the \"governing domain\". The type of the governing +domain depends on the image instantiator format. (Although, more correctly, +it should probably depend on the image instance type.) For example, pixmap +image instances are specific to a device, but widget image instances are +specific to a particular XEmacs window because in order to display such a +widget when two windows onto the same buffer want to display the widget, +two separate underlying widgets must be created. (That's because a widget +is actually a child window-system window, and all window-system windows have +a unique existence on the screen.) This means that the governing domain for +a pixmap image instance will be some device (most likely, the only existing +device), whereas the governing domain for a widget image instance will be +some XEmacs window. + +If you specify an overly general DOMAIN (e.g. a frame when a window was +wanted), an error is signaled. If you specify an overly specific DOMAIN +\(e.g. a window when a device was wanted), the corresponding general domain +is fetched and used instead. For `make-image-instance', it makes no +difference whether you specify an overly specific domain or the properly +general domain derived from it. However, it does matter when creating an +image instance by instantiating a specifier or glyph (e.g. with +`glyph-image-instance'), because the more specific domain causes spec lookup +to start there and proceed to more general domains. (It would also matter +when creating an image instance with an instantiator format of `inherit', +but we currently disallow this. #### We should fix this.) + +If omitted, DOMAIN defaults to the selected window. + NO-ERROR controls what happens when the image cannot be generated. If nil, an error message is generated. If t, no messages are generated and this function returns nil. If anything else, a warning -message is generated and this function returns nil. -*/ - (data, device, dest_types, no_error)) +message is generated and this function returns nil. */ + (data, domain, dest_types, no_error)) { Error_behavior errb = decode_error_behavior_flag (no_error); return call_with_suspended_errors ((lisp_fn_t) make_image_instance_1, Qnil, Qimage, errb, - 3, data, device, dest_types); + 3, data, domain, dest_types); } DEFUN ("image-instance-p", Fimage_instance_p, 1, 1, 0, /* ＠＠ -1438,6 +1511,20 ＠＠ return XIMAGE_INSTANCE_NAME (image_instance); } +DEFUN ("image-instance-domain", Fimage_instance_domain, 1, 1, 0, /* +Return the governing domain of the given image instance. +The governing domain of an image instance is the domain that the image +instance is specific to. It is NOT necessarily the domain that was +given to the call to `specifier-instance' that resulted in the creation +of this image instance. See `make-image-instance' for more information +on governing domains. +*/ + (image_instance)) +{ + CHECK_IMAGE_INSTANCE (image_instance); + return XIMAGE_INSTANCE_DOMAIN (image_instance); +} + DEFUN ("image-instance-string", Fimage_instance_string, 1, 1, 0, /* Return the string of the given image instance. This will only be non-nil for text image instances and widgets. ＠＠ -2878,17 +2965,22 ＠＠ Lisp_Object domain, Lisp_Object instantiator, Lisp_Object depth) { - Lisp_Object device = DOMAIN_DEVICE (domain); Lisp_Object glyph = IMAGE_SPECIFIER_ATTACHEE (XIMAGE_SPECIFIER (specifier)); int dest_mask = XIMAGE_SPECIFIER_ALLOWED (specifier); int pointerp = dest_mask & image_instance_type_to_mask (IMAGE_POINTER); if (IMAGE_INSTANCEP (instantiator)) { - /* make sure that the image instance's device and type are + /* make sure that the image instance's governing domain and type are matching. */ + Lisp_Object governing_domain = XIMAGE_INSTANCE_DOMAIN (instantiator); - if (EQ (device, image_instance_device (instantiator))) + if (DEVICEP (governing_domain) + && EQ (governing_domain, DOMAIN_DEVICE (domain)) + || FRAMEP (governing_domain) + && EQ (governing_domain, DOMAIN_FRAME (domain)) + || WINDOWP (governing_domain) + && EQ (governing_domain, DOMAIN_WINDOW (domain))) { int mask = image_instance_type_to_mask (XIMAGE_INSTANCE_TYPE (instantiator)); ＠＠ -2899,8 +2991,8 ＠＠ instantiator); } else - signal_simple_error_2 ("Wrong device for image instance", - instantiator, device); + signal_simple_error_2 ("Wrong domain for image instance", + instantiator, domain); } else if (VECTORP (instantiator) && EQ (XVECTOR_DATA (instantiator)[0], Qinherit)) ＠＠ -2917,11 +3009,12 ＠＠ Lisp_Object ls3 = Qnil; Lisp_Object pointer_fg = Qnil; Lisp_Object pointer_bg = Qnil; - Lisp_Object cache_domain - = decode_image_instantiator_domain (instantiator, domain); + Lisp_Object governing_domain = + get_image_instantiator_governing_domain (instantiator, domain); + /* We have to put subwindow, widget and text image instances in a per-window cache so that we can see the same glyph in - different windows. We use decode_domain to determine the type + different windows. We use governing_domain to determine the type of image_instance that will be created. */ if (pointerp) ＠＠ -2932,29 +3025,30 ＠＠ } /* First look in the device cache. */ - if (DEVICEP (cache_domain)) + if (DEVICEP (governing_domain)) { subtable = Fgethash (make_int (dest_mask), - XDEVICE (cache_domain)->image_instance_cache, + XDEVICE (governing_domain)-> + image_instance_cache, Qunbound); if (UNBOUNDP (subtable)) { - /* For the image instance cache, we do comparisons with EQ rather - than with EQUAL, as we do for color and font names. - The reasons are: - - 1) pixmap data can be very long, and thus the hashing and - comparing will take awhile. - 2) It's not so likely that we'll run into things that are EQUAL - but not EQ (that can happen a lot with faces, because their - specifiers are copied around); but pixmaps tend not to be - in faces. - - However, if the image-instance could be a pointer, we have to - use EQUAL because we massaged the instantiator into a cons3 - also containing the foreground and background of the - pointer face. - */ + /* For the image instance cache, we do comparisons with + EQ rather than with EQUAL, as we do for color and + font names. The reasons are: + + 1) pixmap data can be very long, and thus the hashing + and comparing will take awhile. + + 2) It's not so likely that we'll run into things that + are EQUAL but not EQ (that can happen a lot with + faces, because their specifiers are copied around); + but pixmaps tend not to be in faces. + + However, if the image-instance could be a pointer, we + have to use EQUAL because we massaged the + instantiator into a cons3 also containing the + foreground and background of the pointer face. */ subtable = make_lisp_hash_table (20, pointerp ? HASH_TABLE_KEY_CAR_WEAK ＠＠ -2962,7 +3056,7 ＠＠ pointerp ? HASH_TABLE_EQUAL : HASH_TABLE_EQ); Fputhash (make_int (dest_mask), subtable, - XDEVICE (cache_domain)->image_instance_cache); + XDEVICE (governing_domain)->image_instance_cache); instance = Qunbound; } else ＠＠ -2971,12 +3065,13 ＠＠ subtable, Qunbound); } } - else if (WINDOWP (cache_domain)) + else if (WINDOWP (governing_domain)) { /* Subwindows have a per-window cache and have to be treated differently. */ - instance = Fgethash (instantiator, - XWINDOW (cache_domain)->subwindow_instance_cache, + instance = + Fgethash (instantiator, + XWINDOW (governing_domain)->subwindow_instance_cache, Qunbound); } else ＠＠ -2989,8 +3084,8 ＠＠ Lisp_Object locative = noseeum_cons (Qnil, noseeum_cons (pointerp ? ls3 : instantiator, - DEVICEP (cache_domain) ? subtable - : XWINDOW (cache_domain) + DEVICEP (governing_domain) ? subtable + : XWINDOW (governing_domain) ->subwindow_instance_cache)); int speccount = specpdl_depth (); ＠＠ -3002,7 +3097,7 ＠＠ record_unwind_protect (image_instantiate_cache_result, locative); instance = - instantiate_image_instantiator (cache_domain, + instantiate_image_instantiator (governing_domain, domain, instantiator, pointer_fg, pointer_bg, dest_mask, glyph); ＠＠ -3022,7 +3117,7 ＠＠ if (image_instance_type_to_mask (XIMAGE_INSTANCE_TYPE (instance)) & (IMAGE_SUBWINDOW_MASK | IMAGE_WIDGET_MASK)) assert (EQ (Fgethash ((pointerp ? ls3 : instantiator), - XWINDOW (cache_domain) + XWINDOW (governing_domain) ->subwindow_instance_cache, Qunbound), instance)); #endif ＠＠ -3254,187 +3349,7 ＠＠ DEFUN ("image-specifier-p", Fimage_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is an image specifier. - -An image specifier is used for images (pixmaps and the like). It is used -to describe the actual image in a glyph. It is instanced as an image- -instance. - -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' - should be added.) -'formatted-string - (Display this image as a text string, with replaceable fields; - not currently implemented.) -'xbm - (An X bitmap; only if X or 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'.) -'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'.) -'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.) -'edit-field - (A text editing widget glyph.) -'button - (A button widget glyph; either a push button, radio button or toggle button.) -'tab-control - (A tab widget glyph; a series of user selectable tabs.) -'progress-gauge - (A sliding widget glyph, for showing progress.) -'combo-box - (A drop list of selectable items in a widget glyph, for editing text.) -'label - (A static, text-only, widget glyph; for displaying text.) -'tree-view - (A folding widget glyph.) -'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.) -'inherit - Inherit from the background-pixmap property of a face. - -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 not valid for instantiator - formats `nothing' and `inherit'.) -: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 not valid for - instantiator formats `nothing', `string', `formatted-string', - `cursor-font', `font', `autodetect', and `inherit'.) -: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.) -:face - (Only for `inherit'. This specifies the face to inherit from. - For widget glyphs 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 widget -glyphs. 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). +See `make-image-specifier' for a description of image instantiators. */ (object)) { ＠＠ -3719,11 +3634,13 ＠＠ DEFUN ("glyphp", Fglyphp, 1, 1, 0, /* Return non-nil if OBJECT is a glyph. -A glyph is an object used for pixmaps and the like. It is used +A glyph is an object used for pixmaps, widgets and the like. It is used in begin-glyphs and end-glyphs attached to extents, in marginal and textual annotations, in overlay arrows (overlay-arrow-* variables), in toolbar -buttons, and the like. Its image is described using an image specifier -- -see `image-specifier-p'. +buttons, and the like. Much more detailed information can be found at +`make-glyph'. Its image is described using an image specifier -- +see `make-image-specifier'. See also `make-image-instance' for further +information. */ (object)) { ＠＠ -4547,10 +4464,10 ＠＠ return IMAGE_SUBWINDOW_MASK; } -Lisp_Object -subwindow_decode_domain (Lisp_Object instantiator, Lisp_Object domain) +int +subwindow_governing_domain (void) { - return DOMAIN_WINDOW (domain); + return GOVERNING_DOMAIN_WINDOW; } /* Partially instantiate a subwindow. */ ＠＠ -4875,7 +4792,6 ＠＠ defsymbol (&Qpointer_image_instance_p, "pointer-image-instance-p"); defsymbol (&Qwidget_image_instance_p, "widget-image-instance-p"); defsymbol (&Qsubwindow_image_instance_p, "subwindow-image-instance-p"); - defsymbol (&Qlayout_image_instance_p, "layout-image-instance-p"); DEFSUBR (Fmake_image_instance); DEFSUBR (Fimage_instance_p); ＠＠ -4883,6 +4799,7 ＠＠ DEFSUBR (Fvalid_image_instance_type_p); DEFSUBR (Fimage_instance_type_list); DEFSUBR (Fimage_instance_name); + DEFSUBR (Fimage_instance_domain); DEFSUBR (Fimage_instance_string); DEFSUBR (Fimage_instance_file_name); DEFSUBR (Fimage_instance_mask_file_name); ＠＠ -5061,12 +4978,14 ＠＠ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (string, "string"); IIFORMAT_HAS_METHOD (string, validate); - IIFORMAT_HAS_SHARED_METHOD (string, decode_domain, subwindow); + IIFORMAT_HAS_SHARED_METHOD (string, governing_domain, subwindow); IIFORMAT_HAS_METHOD (string, possible_dest_types); IIFORMAT_HAS_METHOD (string, instantiate); IIFORMAT_VALID_KEYWORD (string, Q_data, check_valid_string); /* Do this so we can set strings. */ + /* #### Andy, what is this? This is a bogus format and should not be + visible to the user. */ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (text, "text"); IIFORMAT_HAS_METHOD (text, set_property); IIFORMAT_HAS_METHOD (text, query_geometry); ＠＠ -5079,13 +4998,15 ＠＠ IIFORMAT_VALID_KEYWORD (formatted_string, Q_data, check_valid_string); /* Do this so pointers have geometry. */ + /* #### Andy, what is this? This is a bogus format and should not be + visible to the user. */ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (pointer, "pointer"); IIFORMAT_HAS_SHARED_METHOD (pointer, query_geometry, subwindow); /* subwindows */ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (subwindow, "subwindow"); IIFORMAT_HAS_METHOD (subwindow, possible_dest_types); - IIFORMAT_HAS_METHOD (subwindow, decode_domain); + IIFORMAT_HAS_METHOD (subwindow, governing_domain); IIFORMAT_HAS_METHOD (subwindow, instantiate); IIFORMAT_HAS_METHOD (subwindow, query_geometry); IIFORMAT_VALID_KEYWORD (subwindow, Q_pixel_width, check_valid_int); ＠＠ -5234,12 +5155,53 ＠＠ DEFVAR_SPECIFIER ("current-display-table", &Vcurrent_display_table /* *The display table currently in use. This is a specifier; use `set-specifier' to change it. -The display table is a vector created with `make-display-table'. -The 256 elements control how to display each possible text character. -Each value should be a string, a glyph, a vector or nil. -If a value is a vector it must be composed only of strings and glyphs. -nil means display the character in the default fashion. -Faces can have their own, overriding display table. + +Display tables are used to control how characters are displayed. Each +time that redisplay processes a character, it is looked up in all the +display tables that apply (obtained by calling `specifier-instance' on +`current-display-table' and any overriding display tables specified in +currently active faces). The first entry found that matches the +character determines how the character is displayed. If there is no +matching entry, the default display method is used. (Non-control +characters are displayed as themselves and control characters are +displayed according to the buffer-local variable `ctl-arrow'. Control +characters are further affected by `control-arrow-glyph' and +`octal-escape-glyph'.) + +Each instantiator in this specifier and the display-table specifiers +in faces is a display table or a list of such tables. If a list, each +table will be searched in turn for an entry matching a particular +character. Each display table is one of + +-- a vector, specifying values for characters starting at 0 +-- a char table, either of type `char' or `generic' +-- a range table + +Each entry in a display table should be one of + +-- nil (this entry is ignored and the search continues) +-- a character (use this character; if it happens to be the same as + the original character, default processing happens, otherwise + redisplay attempts to display this character directly; + #### At some point recursive display-table lookup will be + implemented.) +-- a string (display each character in the string directly; + #### At some point recursive display-table lookup will be + implemented.) +-- a glyph (display the glyph; + #### At some point recursive display-table lookup will be + implemented when a string glyph is being processed.) +-- a cons of the form (format "STRING") where STRING is a printf-like + spec used to process the character. #### Unfortunately no + formatting directives other than %% are implemented. +-- a vector (each element of the vector is processed recursively; + in such a case, nil elements in the vector are simply ignored) + +#### At some point in the near future, display tables are likely to +be expanded to include other features, such as referencing characters +in particular fonts and allowing the character search to continue +all the way up the chain of specifier instantiators. These features +are necessary to properly display Unicode characters. */ ); Vcurrent_display_table = Fmake_specifier (Qdisplay_table); set_specifier_fallback (Vcurrent_display_table, Index: src/glyphs.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.h,v retrieving revision 1.18.2.47 diff -u -w -r1.18.2.47 glyphs.h --- glyphs.h 2000/05/09 11:26:50 1.18.2.47 +++ glyphs.h 2000/05/09 11:52:40 ＠＠ -50,7 +50,7 ＠＠ tiff color-pixmap bmp color-pixmap cursor-font pointer - mswindows-resource pointer + mswindows-resource pointer, color-pixmap font pointer subwindow subwindow inherit mono-pixmap ＠＠ -62,7 +62,9 ＠＠ tab-control widget tree-view widget scrollbar widget - static widget + label widget + layout widget + native-layout widget */ /* These are methods specific to a particular format of image instantiator ＠＠ -96,6 +98,13 ＠＠ #define WIDGET_BORDER_HEIGHT 4 #define WIDGET_BORDER_WIDTH 4 +enum governing_domain +{ + GOVERNING_DOMAIN_WINDOW, + GOVERNING_DOMAIN_FRAME, + GOVERNING_DOMAIN_DEVICE +}; + struct image_instantiator_methods { Lisp_Object symbol; ＠＠ -120,10 +129,9 ＠＠ Lisp_Object (*normalize_method) (Lisp_Object instantiator, Lisp_Object console_type); - /* Decode domain method: Given an instantiator and a domain, return - a domain appropriate for the instance to be cached in. */ - Lisp_Object (*decode_domain_method) (Lisp_Object instantiator, - Lisp_Object domain); + /* Governing domain method: Return an int indicating what type of + domain an instance in this format is governed by. */ + int (*governing_domain_method) (void); /* Possible-dest-types method: Return a mask indicating what dest types are compatible with this format. */ ＠＠ -346,8 +354,7 ＠＠ void subwindow_instantiate (Lisp_Object image_instance, Lisp_Object instantiator, Lisp_Object pointer_fg, Lisp_Object pointer_bg, int dest_mask, Lisp_Object domain); -Lisp_Object subwindow_decode_domain (Lisp_Object instantiator, - Lisp_Object domain); +int subwindow_governing_domain (void); void widget_instantiate (Lisp_Object image_instance, Lisp_Object instantiator, Lisp_Object pointer_fg, Lisp_Object pointer_bg, int dest_mask, Lisp_Object domain); Index: src/gutter.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/Attic/gutter.c,v retrieving revision 1.1.2.34 diff -u -w -r1.1.2.34 gutter.c --- gutter.c 2000/04/02 12:38:38 1.1.2.34 +++ gutter.c 2000/05/09 11:52:41 ＠＠ -789,14 +789,9 ＠＠ DEFUN ("gutter-specifier-p", Fgutter_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a gutter specifier. -Gutter specifiers are used to specify the format of a gutter. -The values of the variables `default-gutter', `top-gutter', -`left-gutter', `right-gutter', and `bottom-gutter' are always -gutter specifiers. - -Valid gutter instantiators are called "gutter descriptors" and are -either strings or property-lists of strings. See `default-gutter' for -a description of the exact format. + +See `make-gutter-specifier' for a description of possible gutter +instantiators. */ (object)) { ＠＠ -932,15 +927,8 ＠＠ DEFUN ("gutter-size-specifier-p", Fgutter_size_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a gutter-size specifier. -Gutter-size specifiers are used to specify the size of a gutter. The -values of the variables `default-gutter-size', `top-gutter-size', -`left-gutter-size', `right-gutter-size', and `bottom-gutter-size' are -always gutter-size specifiers. - -Valid gutter-size instantiators are either integers or the special -symbol 'autodetect. If a gutter-size is set to 'autodetect them the -size of the gutter will be adjusted to just accomodate the gutters -contents. 'autodetect only works for top and bottom gutters. +See `make-gutter-size-specifier' for a description of possible gutter-size +instantiators. */ (object)) { ＠＠ -977,17 +965,8 ＠＠ DEFUN ("gutter-visible-specifier-p", Fgutter_visible_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a gutter-visible specifier. -Gutter-visible specifiers are used to specify the visibility of a -gutter. The values of the variables `default-gutter-visible-p', -`top-gutter-visible-p', `left-gutter-visible-p', -`right-gutter-visible-p', and `bottom-gutter-visible-p' are always -gutter-visible specifiers. - -Valid gutter-visible instantiators are t, nil or a list of symbols. -If a gutter-visible instantiator is set to a list of symbols, and the -correspondong gutter specification is a property-list strings, then -elements of the gutter specification will only be visible if the -corresponding symbol occurs in the gutter-visible instantiator. +See `make-gutter-visible-specifier' for a description of possible +gutter-visible instantiators. */ (object)) { Index: src/objects.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/objects.c,v retrieving revision 1.5.2.12 diff -u -w -r1.5.2.12 objects.c --- objects.c 2000/05/03 14:47:13 1.5.2.12 +++ objects.c 2000/05/09 11:52:41 ＠＠ -631,19 +631,7 ＠＠ DEFUN ("color-specifier-p", Fcolor_specifier_p, 1, 1, 0, /* Return t if OBJECT is a color specifier. -Valid instantiators for color specifiers are: - --- a string naming a color (e.g. under X this might be "lightseagreen2" - or "#F534B2") --- a color instance (use that instance directly if the device matches, - or use the string that generated it) --- a vector of no elements (only on TTY's; this means to set no color - at all, thus using the "natural" color of the terminal's text) --- a vector of one or two elements: a face to inherit from, and - optionally a symbol naming which property of that face to inherit, - either `foreground' or `background' (if omitted, defaults to the same - property that this color specifier is used for; if this specifier is - not part of a face, the instantiator would not be valid) +See `make-color-specifier' for a description of possible color instantiators. */ (object)) { ＠＠ -840,17 +828,8 ＠＠ DEFUN ("font-specifier-p", Ffont_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a font specifier. - -Valid instantiators for font specifiers are: --- a string naming a font (e.g. under X this might be - "-*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-*" for a 14-point - upright medium-weight Courier font) --- a font instance (use that instance directly if the device matches, - or use the string that generated it) --- a vector of no elements (only on TTY's; this means to set no font - at all, thus using the "natural" font of the terminal's text) --- a vector of one element (a face to inherit from) +See `make-font-specifier' for a description of possible font instantiators. */ (object)) { ＠＠ -985,16 +964,9 ＠＠ DEFUN ("face-boolean-specifier-p", Fface_boolean_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a face-boolean specifier. - -Valid instantiators for face-boolean specifiers are --- t or nil --- a vector of two or three elements: a face to inherit from, - optionally a symbol naming the property of that face to inherit from - (if omitted, defaults to the same property that this face-boolean - specifier is used for; if this specifier is not part of a face, - the instantiator would not be valid), and optionally a value which, - if non-nil, means to invert the sense of the inherited property. +See `make-face-boolean-specifier' for a description of possible +face-boolean instantiators. */ (object)) { Index: src/redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.55 diff -u -w -r1.55.2.55 redisplay.c --- redisplay.c 2000/05/03 14:47:16 1.55.2.55 +++ redisplay.c 2000/05/09 11:52:44 ＠＠ -1322,6 +1322,7 ＠＠ case '%': dst += set_charptr_emchar (dst, '%'); break; + /* #### unimplemented */ } } } ＠＠ -3980,8 +3981,8 ＠＠ * - If first element is another symbol, process the cadr or caddr * recursively according to whether the symbol's value is non-nil or * nil. - * - If first element is a face, process the cdr recursively - * without altering the depth. + * - If first element is an extent, process the cdr recursively + * and handle the extent's face. */ Lisp_Object car, tem; ＠＠ -9320,7 +9321,9 ＠＠ Voverlay_arrow_position = Qnil; DEFVAR_LISP_MAGIC ("overlay-arrow-string", &Voverlay_arrow_string /* -String to display as an arrow. See also `overlay-arrow-position'. +String or glyph to display as an arrow. See also `overlay-arrow-position'. +(Note that despite the name of this variable, it can be set to a glyph as +well as a string.) */ , redisplay_variable_changed); Voverlay_arrow_string = Qnil; Index: src/specifier.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/specifier.c,v retrieving revision 1.15.2.18 diff -u -w -r1.15.2.18 specifier.c --- specifier.c 2000/05/03 14:47:17 1.15.2.18 +++ specifier.c 2000/05/09 11:52:46 ＠＠ -532,31 +532,51 ＠＠ A specifier is an object that can be used to keep track of a property whose value can be per-buffer, per-window, per-frame, or per-device, -and can further be restricted to a particular console-type or device-class. -Specifiers are used, for example, for the various built-in properties of a -face; this allows a face to have different values in different frames, -buffers, etc. For more information, see `specifier-instance', +and can further be restricted to a particular console-type or +device-class. Specifiers are used, for example, for the various +built-in properties of a face; this allows a face to have different +values in different frames, buffers, etc. + +When speaking of the value of a specifier, it is important to +distinguish between the *setting* of a specifier, called an +\"instantiator\", and the *actual value*, called an \"instance\". You +put various possible instantiators (i.e. settings) into a specifier +and associate them with particular locales (buffer, window, frame, +device, global), and then the instance (i.e. actual value) is +retrieved in a specific domain (window, frame, device) by looking +through the possible instantiators (i.e. settings). This process is +called \"instantiation\". + +To put settings into a specifier, use `set-specifier', or the +lower-level functions `add-spec-to-specifier' and +`add-spec-list-to-specifier'. You can also temporarily bind a setting +to a specifier using `let-specifier'. To retrieve settings, use +`specifier-specs', or its lower-level counterpart +`specifier-spec-list'. To determine the actual value, use +`specifier-instance'. + +For more information, see `set-specifier', `specifier-instance', `specifier-specs', and `add-spec-to-specifier'; or, for a detailed -description of specifiers, including how they are instantiated over a -particular domain (i.e. how their value in that domain is determined), -see the chapter on specifiers in the XEmacs Lisp Reference Manual. +description of specifiers, including how exactly the instantiation +process works, see the chapter on specifiers in the XEmacs Lisp +Reference Manual. TYPE specifies the particular type of specifier, and should be one of -the symbols 'generic, 'integer, 'boolean, 'color, 'font, 'image, -'face-boolean, 'gutter, 'gutter-size, 'gutter-visible or 'toolbar. +the symbols 'generic, 'integer, 'natnum, 'boolean, 'color, 'font, +'image, 'face-boolean, 'display-table, 'gutter, 'gutter-size, +'gutter-visible or 'toolbar. For more information on particular types of specifiers, see the -functions `generic-specifier-p', `integer-specifier-p', -`boolean-specifier-p', `color-specifier-p', `font-specifier-p', -`image-specifier-p', `face-boolean-specifier-p', `gutter-specifier-p, -`gutter-size-specifier-p, `gutter-visible-specifier-p and -`toolbar-specifier-p'. -*/ +functions `make-generic-specifier', `make-integer-specifier', +`make-natnum-specifier', `make-boolean-specifier', +`make-color-specifier', `make-font-specifier', `make-image-specifier', +`make-face-boolean-specifier', `make-gutter-size-specifier', +`make-gutter-visible-specifier', `default-toolbar', `default-gutter', +and `current-display-table'. */ (type)) { /* This function can GC */ - struct specifier_methods *meths = decode_specifier_type (type, - ERROR_ME); + struct specifier_methods *meths = decode_specifier_type (type, ERROR_ME); return make_specifier (meths); } ＠＠ -620,6 +640,7 ＠＠ return ((DEVICEP (domain) && DEVICE_LIVE_P (XDEVICE (domain))) || (FRAMEP (domain) && FRAME_LIVE_P (XFRAME (domain))) || (WINDOWP (domain) && WINDOW_LIVE_P (XWINDOW (domain))) || + /* #### get image instances out of domains! */ IMAGE_INSTANCEP (domain)) ? Qt : Qnil; } ＠＠ -732,7 +753,7 ＠＠ signal_simple_error ("Invalid specifier domain", domain); } -static Lisp_Object +Lisp_Object decode_domain (Lisp_Object domain) { if (NILP (domain)) ＠＠ -2518,6 +2539,7 ＠＠ /* Attempt to determine buffer, window, frame, and device from the domain. */ + /* #### get image instances out of domains! */ if (IMAGE_INSTANCEP (domain)) window = DOMAIN_WINDOW (domain); else if (WINDOWP (domain)) ＠＠ -2527,9 +2549,10 ＠＠ else if (DEVICEP (domain)) device = domain; else - /* #### dmoore - dammit, this should just signal an error or something - shouldn't it? - #### No. Errors are handled in Lisp primitives implementation. + /* dmoore writes: [dammit, this should just signal an error or something + shouldn't it?] + + No. Errors are handled in Lisp primitives implementation. Invalid domain is a design error here - kkm. */ abort (); ＠＠ -2964,9 +2987,10 ＠＠ What really needs to be done is to write a function `make-specifier-type' that creates new specifier types. - #### I'll look into this for 19.14. - */ + #### [I'll look into this for 19.14.] Well, sometime. (Currently + May 2000, 21.2 is in development. 19.14 was released in June 1996.) */ + "A generic specifier is a generalized kind of specifier with user-defined\n" "semantics. The instantiator can be any kind of Lisp object, and the\n" "instance computed from it is likewise any kind of Lisp object. The\n" ＠＠ -3002,8 +3026,8 ＠＠ DEFUN ("generic-specifier-p", Fgeneric_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a generic specifier. -A generic specifier allows any kind of Lisp object as an instantiator, -and returns back the Lisp object unchanged when it is instantiated. +See `make-generic-specifier' for a description of possible generic +instantiators. */ (object)) { ＠＠ -3025,6 +3049,9 ＠＠ DEFUN ("integer-specifier-p", Finteger_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is an integer specifier. + +See `make-integer-specifier' for a description of possible integer +instantiators. */ (object)) { ＠＠ -3045,6 +3072,9 ＠＠ DEFUN ("natnum-specifier-p", Fnatnum_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a natnum (non-negative-integer) specifier. + +See `make-natnum-specifier' for a description of possible natnum +instantiators. */ (object)) { ＠＠ -3066,6 +3096,9 ＠＠ DEFUN ("boolean-specifier-p", Fboolean_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a boolean specifier. + +See `make-boolean-specifier' for a description of possible boolean +instantiators. */ (object)) { ＠＠ -3114,6 +3147,9 ＠＠ DEFUN ("display-table-specifier-p", Fdisplay_table_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a display-table specifier. + +See `current-display-table' for a description of possible display-table +instantiators. */ (object)) { Index: src/specifier.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/specifier.h,v retrieving revision 1.6.2.12 diff -u -w -r1.6.2.12 specifier.h --- specifier.h 2000/05/03 14:47:18 1.6.2.12 +++ specifier.h 2000/05/09 11:52:46 ＠＠ -413,6 +413,12 ＠＠ Lisp_Object oldval); }; +/* #### get image instances out of domains! */ + +/* #### I think the following should abort() rather than return nil + when an invalid domain is given; much more likely we'll catch design + errors early. --ben */ + /* This turns out to be used heavily so we make it a macro to make it inline. Also, the majority of the time the object will turn out to be a window so we move it from being checked last to being checked ＠＠ -462,6 +468,7 ＠＠ extern enum spec_add_meth decode_how_to_add_specification (Lisp_Object how_to_add); Lisp_Object decode_specifier_tag_set (Lisp_Object tag_set); +Lisp_Object decode_domain (Lisp_Object domain); void add_entry_to_specifier_type_list (Lisp_Object symbol, struct specifier_methods *meths); Index: src/toolbar.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/toolbar.c,v retrieving revision 1.18.2.8 diff -u -w -r1.18.2.8 toolbar.c --- toolbar.c 2000/03/29 18:35:35 1.18.2.8 +++ toolbar.c 2000/05/09 11:52:47 ＠＠ -1160,14 +1160,9 ＠＠ DEFUN ("toolbar-specifier-p", Ftoolbar_specifier_p, 1, 1, 0, /* Return non-nil if OBJECT is a toolbar specifier. -Toolbar specifiers are used to specify the format of a toolbar. -The values of the variables `default-toolbar', `top-toolbar', -`left-toolbar', `right-toolbar', and `bottom-toolbar' are always -toolbar specifiers. -Valid toolbar instantiators are called "toolbar descriptors" -and are lists of vectors. See `default-toolbar' for a description -of the exact format. +See `make-toolbar-specifier' for a description of possible toolbar +instantiators. */ (object)) { Index: src/window.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/window.c,v retrieving revision 1.41.2.50 diff -u -w -r1.41.2.50 window.c --- window.c 2000/05/09 11:26:51 1.41.2.50 +++ window.c 2000/05/09 11:52:49 ＠＠ -1875,6 +1875,9 ＠＠ window_unmap_subwindows_cache_mapper (Lisp_Object key, Lisp_Object value, void *flag_closure) { + /* value can be nil; we cache failures as well as successes */ + if (!NILP (value)) + { struct frame* f = XFRAME (XIMAGE_INSTANCE_FRAME (value)); unmap_subwindow (value); /* In case GC doesn't catch up fast enough, remove from the frame ＠＠ -1882,6 +1885,7 ＠＠ will fail. */ XWEAK_LIST_LIST (FRAME_SUBWINDOW_CACHE (f)) = delq_no_quit (value, XWEAK_LIST_LIST (FRAME_SUBWINDOW_CACHE (f))); + } return 0; } -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/chronic-pain/