Re: Changing pointer glyph

Byrel Mitchell writes: > (set-glyph-image text-pointer-glyph [ xpm :file > "I://xemacs_macros//test.xpm" ]) I seem to recall there's a bug here, that image instances do not get automatically updated when the pointer specifier changes. I seem to also recall that `set-specifier-dirty-flag' doesn't help (that may apply only to toolbars, though -- you should try it in your application). I never followed up; the code is extremely complicated and has substantial performance implications, and "sticky glyphs" rarely cause problems.

> I'm not sure why exactly an instance behaves differently from an > instantiator, or if there is some extra command I would need to run > to update to the new cursor when using an instantiator. Instantiators are uniform descriptions which will induce different (platform-dependent) behavior, aka "instances", in various situations. (The most important distinction is that instantiation may fail, such as instantiation of an image on a TTY, and the specifier code will automatically try a lower priority instantiator.) Creating an instance is often very expensive (for example, creating an image on X11 involves X protocol and therefore network delays), so the currently active instances are cached. Instances are a special type of object which is directly displayable by the redisplay machinery, so if an instance is passed in, XEmacs knows that, and can and does just update the pointer in the cache immediately, and this can be done safely except when in a critical section of redisplay. On the other hand, if an instantiator is passed in, the locale specification is updated, but the instance is only updated as-needed, ie, on the next redisplay of the object in a matching domain -- which may be never. The distinction between locales (which are indexes into the specification) and domains (which are indexes into the specifier cache) is that locales may span hardware (a buffer is a locale, and it may be displayed simultaneously on the MS Windows console, on an X11 display, and on a TTY), while domains refer to a specific set of windows which are constrained to be on the same hardware (and therefore the same instance is necessarily usable). While this distinction doesn't matter much to your application of editing XPMs which pretty much requires GUI on the current console, it does matter a lot to me as I edit this message in a Terminal.app window on Mac OS X while XEmacs runs on a Linux machine 10km away. N.B. I don't know the full history, but my guess is that things related to domains are said to be "selected" (device, frame, window) while things that are related to locales and may span multiple domains are said to be "current". That terminology may precede the specifier implementation though. In most cases, instances are very long-lasting, usually until the end of the XEmacs session. Most of the time when a specifier's appearance changes, it's not because that "slot" in the specifier has changed, but rather because the "focus" is in a different domain (such as a different frame or Emacs window), and a different instance is being used, one appropriate to the changed context. This is especially true of images (including cursor glyphs), since they are rarely edited in Emacs. Note that an instance of appropriate type is always acceptable as a value to a specifier, as long as it is generated for some domain accessible to the running XEmacs, because it can simply be inserted in the instance cache.