Thanks for the explanation!
So, if I understand correctly, maybe I should set the specifier first to an
instance, and then to the base specification. That way, I can get it to
update now, but if it needs to be reevaluated on a different domain, it can
be. This would be an issue on frames running on different graphical devices
(different X servers, displays, screens, etc.)
I'm attaching a patch for the documentation for set-glyph-image (in
glyphs.el). Just adds that you can pass in an image instance.
Sincerely,
Byrel
On Thu, Jul 14, 2011 at 7:37 PM, Stephen J. Turnbull <stephen(a)xemacs.org>wrote:
Byrel Mitchell writes:
> Based on the Lispref->Glyphs->Using Glyphs->External-Glyphs section of
the
> documentation, I thought I should be able to pass an image instantiator
into
> set-glyph-image; something like:
>
> (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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta