Stephen J. Turnbull wrote:
Could you please explain what this patch does, specifically why the
no-fallback behavior is needed wherever it was that you added it?
Sure. Technically, what it does is pretty simple: it propagates the
no_fallback flag at places where it was missing before. I'll explain in
greater detail below.
I assume this has something to do with your background image problem;
I don't have an image problem anymore :-) But yes, I've noticed the
bug because of my background pixmap. I suspect however that the patch
fixes a more general problem.
Here's what was happening:
- I have a background pixmap and a background color set in my default face.
- my font-lock-string-face has a foreground color set, and that's all.
When it is in use, I was correctly seing the background pixmap behind
- slime-repl-output-face is defined as (:inherit font-lock-string-face).
However, the background was drawn with the color, not the pixmap.
The problem was that a call to:
(face-property-instance font-lock-string-face 'background nil nil t)
correctly returned Qunbound, but
(face-property-instance 'slime-repl-output-face 'background nil nil t)
incorrectly returned a instantiated background color.
That was because the instantiation process invoked specifier-instance on
the inheritance special construct (an array containing
font-lock-string-face), which in turned invoked specifier-instance on
the font-lock-string-face background property, but this time without the
This is why I think my patch fixes a more general problem than only the
one I was experimenting: probably all instantiations of properties
defined by inheritance.
A patch would be nice, but if you don't feel like hacking texi, I
do that part.
I don't mind doing it, but I have no idea where you would like to see
this happening, given that it's a bug fix. Unless the bug is
"documented" somewhere of course :-)
It doesn't look like you actually fixed specifier inheritance
behavior; this option was available all along in specifiers
Rather you added no-fallback behavior to images or something that
Nope. I hope it's clearer now ?
Did you ever post a patch (besides that auto-commit notice)? I
recall seeing it, and Vin responded to the commit notice....
Err, no, because it was my understanding that after the transition to
mercurial, we were not supposed to do so anymore, precisely because the
automatic commit notice was doing that. See the new chapter in Patcher's
documentation... which I might have to rewrite then ?? :-/
What was all the whitespace fiddling doing i nthat patch?
It's my auto-cleanup that's been at work since I started hacking in
XEmacs 14 years ago. You've never noticed before probably because the
patches I explicitely sent to xeamcs-patches＠ with Patcher were
whitespace-clean (remember the "this patch in informational only..."
mention at the top of Patcher posts).
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org
XEmacs-Patches mailing list