Re: [COMMIT] Apply Stephen's bugfix to my advice.el changes

Aidan Kehoe writes: > This syntax works, though, and also doesn’t provoke any complaints > on FreeBSD: > > (make-glyph `(((mswindows) . [xbm :data (6 20 ,(make-string 20 0))]) > ((tty) . [string :data " "]))) This syntax works because you have X support built in on FreeBSD, right?

The whole point of my example is to use a valid instantiator format that is unknown to the XEmacs instance.

> On FreeBSD, when I build without X11 support, I can provoke the error that > is blocking the build on evaluating the code in x-symbol-vars.el. Mats, I > suspect, but haven’t confirmed, that the following will allow the build to > continue, I can certainly evaluate it without problems: > > --- x-symbol-vars.el~ 2010-07-25 17:58:39.000000000 +0100 > +++ x-symbol-vars.el 2010-07-25 17:53:53.000000000 +0100 > ＠＠ -1099,7 +1099,8 ＠＠ > :group 'x-symbol-input-init) > > (defvar x-symbol-heading-strut-glyph > - (make-glyph (eval-when-compile > + (make-glyph (remove-if-not > + #'(lambda (spec) (valid-instantiator-p (cdr spec) 'image)) > `(((x) . [xbm :data (6 20 ,(make-string 20 0))]) > ((mswindows) . [xbm :data (6 20 ,(make-string 20 0))]) > ((tty) . [string :data " "])))) Not your fault, but if that is needed, something is seriously wrong with the implementation of make-glyph. The whole point of specifiers is to allow you to specify things that may or may not be reasonable for the current instance of XEmacs, and have XEmacs intelligently filter out nonsense. The device-type guards should serve that purpose.

> We also really should apply something like the following in specifier.el, > which would have made the whole thing a lot easier to debug (misleading > error messages never make anything easy): Improving the error message seems reasonable to me. It doesn't need to be perfect if you can make it better. It does need some test cases, though.