GNU bug report logs - #2066
Face `unspecified' inheritance ignores face-remapping-alist

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2066 in the body.
You can then email your comments to 2066 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Face `unspecified' inheritance ignores face-remapping-alist
Date: Mon, 26 Jan 2009 09:46:48 -0500

[Message part 1 (text/plain, inline)]

Faces with an unspecified `inherit' attribute inherit from `default',  
right?

Unfortunately, this mechanism does not respect remapped faces (face- 
remapping-alist).  Faces, by default, seem to inherit from the frame  
default.  To demonstrate:

emacs -Q
(fundamental-mode)
(setq face-remapping-alist '((default . highlight)))
(insert (propertize "test" 'face 'fringe))

In a concrete use case, `csv-mode' fails to align its columns when  
face-remapping-alist is used, because one of its faces is not  
specified to inherit from default, causing it to inherit from the  
wrong face (see screenshot).

[pastedGraphic.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

[smime.p7s (application/pkcs7-signature, attachment)]

Message #10 received at 2066 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 2066 <at> debbugs.gnu.org
Subject: Re: Face `unspecified' inheritance ignores face-remapping-alist
Date: Tue, 27 Jan 2009 14:16:40 -0500

> Faces with an unspecified `inherit' attribute inherit from `default',  
> right?
>
> Unfortunately, this mechanism does not respect remapped faces (face- 
> remapping-alist).  Faces, by default, seem to inherit from the frame  
> default.  To demonstrate:
>
> emacs -Q
> (fundamental-mode)
> (setq face-remapping-alist '((default . highlight)))
> (insert (propertize "test" 'face 'fringe))

I don't see any bug here.  The "test" string inserted into the buffer
has a background different from `highlight', but that's because its
background is not unspecified:

(defface fringe
  '((((class color) (background light))
     :background "grey95")
    (((class color) (background dark))
     :background "grey10")
    (t
     :background "gray"))
  "Basic face for the fringes to the left and right of windows under X."
  :version "21.1"
  :group 'frames
  :group 'basic-faces)

Message #15 received at 2066 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 2066 <at> debbugs.gnu.org
Subject: Re: Face `unspecified' inheritance ignores face-remapping-alist
Date: Tue, 27 Jan 2009 15:46:44 -0500

[Message part 1 (text/plain, inline)]

On 27 Jan 2009, at 14:16, Chong Yidong wrote:
>
> I don't see any bug here.  The "test" string inserted into the buffer
> has a background different from `highlight', but that's because its
> background is not unspecified:

You are right, mea culpa.  My test case wasn't correct.

To reproduce, we also need overlays with before/after-string properties.

To demonstrate:

(require 'csv-mode)
(csv-mode)
(set (make-local-variable 'face-remapping-alist) '((default .  
highlight)))

Enter something like this:

8,1,4,5
9912919,112312,543453,444

Mark all, then C-c C-a  (csv-align-fields)

The result, for me at least, is shown in the first screenshot.

CSV-Mode uses overlays for the separators.  From my brief analysis of  
the code (`csv-align-fields'), it seems to use overlays with `before- 
string' and `after-string' properties to mark spaces to the left and  
to the right of each field. (In the code, right after "Display spaces  
before field:" and ";; Display spaces after field:")
This `before-string' is not rendered using the correct face, i.e. it  
does not respect face-remapping-alist. This can be seen in the  
screenshots.

I suspect that the `before-string' overlays are rendered using the  
adjacent face for the comma, which is, per font-locking, set to `csv- 
separator-face'.  And that is where the inheritance issue plays a  
role.  If you M-x customize-face csv-separator-face, and set the  
`inherit' attribute to default, then you should see things change  
(screenshot 1 to 2).  Setting the inheritance to `default'  should  
never result in any visible change.

I'm sure I could provide a minimal example if I had more time, but I  
hope that the analysis was enough to let you reproduce this issue with  
`before-string' and `after-string'.

PS: The practical problem for the user was not a matter of background  
colors, but to choose a fixed-width font for `csv-mode' buffers when  
the `default' face is variable-width, in order to get the numbers to  
align properly.

[pastedGraphic.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

[pastedGraphic.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

[smime.p7s (application/pkcs7-signature, attachment)]

Message #20 received at 2066 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: 2066 <at> debbugs.gnu.org
Subject: Re: Face `unspecified' inheritance ignores face-remapping-alist
Date: Tue, 27 Jan 2009 15:57:20 -0500

[Message part 1 (text/plain, inline)]

one more thing:

I find that Emacs 23 handles one of the two properties (I think it's  
after-string) correctly, and the other one (before-string?) as I've  
described.
And it doesn't seem to depend on font-locking

[smime.p7s (application/pkcs7-signature, attachment)]

Message #23 received at 2066 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 2066 <at> debbugs.gnu.org
Subject: Re: bug#2066: Face `unspecified' inheritance ignores
	face-remapping-alist
Date: Sat, 09 Jun 2012 17:38:49 +0800

David Reitter <david.reitter <at> gmail.com> writes:

>> I don't see any bug here.  The "test" string inserted into the buffer
>> has a background different from `highlight', but that's because its
>> background is not unspecified:
>
> You are right, mea culpa.  My test case wasn't correct.
>
> To reproduce, we also need overlays with before/after-string
> properties.

Fixed in trunk.  Thanks for pointing this bug out.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.