The idea that set-specifier could take spec-lists and lists of instantiators and
similar crap was a horrible design flaw on my part. I realized this years ago
but unfortunately this was after a release of XEmacs had already happened. to
mitigate this, there's lots of complicated stuff to try and figure out if lists
are potentially interpretable as instantiators and interpret them that way; but
overall it's way too complicated.
i would suggest something like this:
[1] modify the set-specifier API so it no longer allows so much crap. if people
want to do such things, they can just one of the canonicalize-* functions to
convert to the proper format, then call add-spec-list-to-specifier. i doubt
anyone is actually using set-specifier this way in any case.
[2] if you guys have some better ideas for how the specifier API's ought to
work, flesh them out and i'll see about adding them. i still remember pretty
well how this all works so it shouldn't be too hard.
ben
----- Original Message -----
From: "Stephen J. Turnbull" <stephen(a)xemacs.org>
To: "Stephen J. Turnbull" <stephen(a)xemacs.org>
Cc: "Jerry James" <james(a)xemacs.org>; <ben(a)666.com>; "XEmacs
Beta"
<xemacs-beta(a)xemacs.org>; "Klaus Berndl" <klaus.berndl(a)sdm.de>
Sent: Sunday, January 18, 2004 8:55 PM
Subject: Re: make-variable-frame-local in XEmacs available or something similar?
>>>>> "sjt" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>>> "Jerry" == Jerry James <james(a)xemacs.org> writes:
Jerry> Now I add an instantiator for that frame:
Jerry> (set-specifier my-frame-local-var t (selected-frame))
Jerry> my-frame-local-var => #<generic-specifier global=(#<x-frame
Jerry> "emacs" 0xf21> . t) 0x19df>
Jerry> What's going on here? The default of nil has disappeared!
Jerry> Well, that must mean that I did something wrong,
sjt> Something is badly broken here (XEmacs 21.4.12 and 21.5.16),
sjt> because I can't get that specifier to accept a frame spec,
sjt> either.
Reconfirmed.
Jerry> Yet we've all had trouble figuring out how to do something
Jerry> simple and fundamental with specifiers. That says
Jerry> something very unflattering about the specifier
Jerry> documentation.
sjt> It looks to me like generic specifiers are just plain broken,
sjt> as I can't even get `add-spec-list-to-specifier' to do what I
sjt> expect it to do. This is true for both 21.4.12 and 21.5.16
sjt> (+ some updates).
I still don't know exactly what's going wrong, but I'll offer the
following observations as workarounds.
1. The set-specifier implementation is broken, at least for generic
specifiers. IMHO the API design is broken, since it accepts all
of: instantiators, lists of instantiators, and spec-lists (not to
mention other stuff), but these are hard to distinguish for both
generic specifiers and toolbar specifiers (at least), which accept
lists as instantiators.
Use `add-spec-to-specifier', which in limited testing seems to be
OK, and whose API seems to be identical to the principal variant
of set-specifier.
`add-spec-list-to-specifier' _is_ quite confusing and hard to use;
practical use pretty much requires backquote notation which is
basically the equivalent of "double diamonds" on the ski slopes.
I get the feeling it's probably only really useful in an idiom like
(defvar my-saved-specs)
(setq my-saved-specs (specifier-spec-list some-specifier))
;; work with the specifier
;; restore saved specs
(remove-specifier some-specifier 'all)
(add-spec-list-to-specifier some-specifier my-saved-specs)
2. The print-internal-object function for generic specifiers works
differently than those for images, etc. It seems to print _only_
the global spec; locale-specific specs are hidden.
You must use `specifier-spec-list' (or the convenience API
`specifier-specs') to get the mapping.
I'll see about updating the docs later today or tomorrow.
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.