bug#2066: Face `unspecified' inheritance ignores face-remapping-alist

bug#2066: Face `unspecified' inheritance ignores face-remapping-alist

[David Reitter]

[-- Attachment #1.1: Type: text/plain, Size: 605 bytes --]

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).



[-- Attachment #1.2: pastedGraphic.png --]
[-- Type: image/png, Size: 77717 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 2 bytes --]




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#2066: Face `unspecified' inheritance ignores face-remapping-alist

[Chong Yidong]

> 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)

bug#2066: Face `unspecified' inheritance ignores face-remapping-alist

[David Reitter]

[-- Attachment #1.1: Type: text/plain, Size: 2002 bytes --]

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.


[-- Attachment #1.2: pastedGraphic.png --]
[-- Type: image/png, Size: 3271 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 3 bytes --]





[-- Attachment #1.4: pastedGraphic.png --]
[-- Type: image/png, Size: 3311 bytes --]

[-- Attachment #1.5: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#2066: Face `unspecified' inheritance ignores face-remapping-alist

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 214 bytes --]

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

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#2066: Face `unspecified' inheritance ignores face-remapping-alist

[Chong Yidong]

David Reitter <david.reitter@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.