commit: Fix specifier inheritance behavior

[Didier Verna]

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
  the text.
- 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
no_fallback flag.

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 can
> 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
> themselves.

  No comprendo.


> Rather you added no-fallback behavior to images or something that uses
> images, right?

  Nope. I hope it's clearer now ?


> Did you ever post a patch (besides that auto-commit notice)? I don't
> 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 at 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 at xemacs.org