What you say about the way magic specifiers appear at the Lisp level is correct. However,
really don't think you should add needless extra parameters to any specifier
Instead, just decide that specifier-fallback definitely does not copy a specifier that it
returns, and maybe add a read only flag to specifiers if you don't want the ghost
to be modified except during initialization time. For that matter, there would be no need
call copy-tree at all if it were possible to mark conses and vectors (and strings) as
read-only. This should be possible using minimal tag bits, and I think it would be a
feature to add as it would eliminate a lot of other places where lists are copied solely
avoid possible malicious code modifying them. Kyle? You could simulate this in the non-
minimal tag bits case by allocating read-only conses in their own frob blocks, and
figure out a way to hack the flag into strings and vectors.
Kirill M. Katsnelson wrote:
Some time ago, Ben Wing wrote...
| For the most part this looks very good, but I don't like the reveal ghost
| mechanism. Instead, why don't you just have a flag that indicates whether the
| specifiers are read-only? This is true except during those Lisp initialization
| functions, which retrieve the ghost specifier using specifier-fallback. In your
| current scheme, unless I'm mistaken, naughty code could retrieve the ghost
| using specifier-fallback, and then modify it.
Oops, you are right, specifier-fallback uses copy-tree to return the fallback value,
but copy-tree does not copy specifiers, just returns its argument. Maybe copy-tree
and copy-sequence should be extended to the specifier case? Specifiers *are* the
objects copying which makes sence. Implementation is 2 lines of code worthy...
As for the reveal mechanism, I designed it with minimal changes to the hairy
initialization lisp code in mind. Anyways, what you propose really makes the design
clearer, and overweighs my consideration.
To avoid dependency on the behavior of specifier-fallback, i.e. whether it copies a
fallback specifier or not, may it be better to add one parameter to add-spec* and
remove-spec* functions, telling that these should operate on the ghost part of a
magic specifier, if it is really magic? This gives (maybe little) benefit in so that
lisp code should not care whether a specifier is a magic one, i.e. does it have a
ghost fallback or not.
| The purpose of the depth argument that you [Kirill] ask about is to catch inheritance
| loops, but I do not know if this is currently implemented.
Yes, this is implemented.
I already found out why this counter is passed to instantiate method: For faces, this
method may call specifier_instance again, with matchspec this time, thus possibly
creating an "external" loop, so it passes the counter back to
I will document the usage of this parameter.
| As for your suggestion about comparing fallbacks in the internal equal method, I
| this is a good idea.
Ok, I will add this.
| I'm glad that you documented the specifier methods, and I'm impressed with
| thoroughness and the clearness of the documentation.
| I think that you should add to the comment that explains magic specifiers, noting the
| difference between the ghost fallbacks (which contain the user preferences specified
| through window system resource files), and the fallback of the ghost fallback (which
| contains emergency backup values just to make sure that something minimally
And this, too.
I do not think that magic specifications should be documented at lisp level. For a lisp
program, a magic specifier is just a regular specifier, with another specifier as its
fallback, and there is nothing magic about it. Am I correct here?
This message composed using voice recognition software and foot pedals.
(No keyboards were harmed while composing this message.)